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ABSTRACT 


This dissertation addresses the need for a formal method to support the merging of 
changes in independently developed versions of a prototype in a computer-aided rapid pro¬ 
totyping system. The goal is to provide the prototype developer with the ability to: combine 
independently developed enhancements to a prototype, check for consistency, and automat¬ 
ically update all derived versions of a prototype with changes made to the base version. 

A useful semantics-based method is provided for change-merging that is guaranteed to 
detect all conflicts. Prototype slicing is used to capture the affected parts of each variation 
and the preserved part of the base in both variations. We then combine the affected parts 
with the preserved part using our model, which includes the first use of Brouwerian Algebras 
to formalize the merging of hard real time constraints. Our Slicing Theorem guarantees that 
this method produces a prototype that correctly exhibits the significant behavior of each of 
the input versions, provided the changes do not conflict. The method achieves correctness 
by comparing the slice of the change-merged version with respect to each affected part 
against the same slice of the appropriate changed version. If the slices are the same, the 
change-merge is correct, otherwise a diagnostic message results. A preliminary conditional 
method for change-merging while programs is also provided that is strictly more accurate 
than previous methods. 

This dissertation contributes to computer-aided software maintenance by providing a 
model, algorithm and implementation for an automated change-merging tool for PSDL pro¬ 
totypes. Preliminary testing shows that this tool will enhance the ability of the prototype 
developer to deliver a prototype in less time by enabling more concurrency in the develop¬ 
ment effort. 
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I. INTRODUCTION 


During iterative development of software prototypes, different variations are generally 
developed where each of the versions contains a portion of the desired capability. Because 
these prototypes can be very large, tools that automatically determine the differences be¬ 
tween these versions and produce a new version exhibiting significant behavior from each 
are desirable. This dissertation defines a change-merging method that is semantics-based 
and guarantees that if a conflict-free result is produced, it is semantically correct, and pro¬ 
vides a working change-merging tool to be integrated into the Computer-Aided Prototyping 
System (CAPS). Traditional syntax-based merging tools fall short of providing results guar¬ 
anteed to be semantically correct, and earlier semantics-based change-merging or integration 
methods concentrated on combining changes to simple imperative or while programs. We 
explore a domain of enhanced data flow programs, written in PSDL, which are inherently 
non-deterministic and peirallel. Our change-merging method provides the first real change¬ 
merging capability for this domain of programs. 

Software change-merging is also applicable to software maintenance activities. As¬ 
suming that a software system has been developed using the computer-aided prototyping 
paradigm, or can be translated into the prototyping language, different versions of that soft¬ 
ware can be automatically updated with changes made to the base version by applying our 
method. The fielded version would be one variation and the updated base version would 
be the other variation. If all of the changes made to the base version are compatible with 
the fielded version, applying our method results in a new fielded version updated with the 
changes made to the base version. If the changes are not compatible, this information is pro¬ 
vided automatically by our method. Using this technology eliminates the need for software 
designers to manually check if changes are compatible before performing updates. It also 





allows fewer designers to make changes to existing software systems, as well as prototypes 
in development. In an industry with projected costs in the billions of dollars [Ref. 40], this 
translates into significant savings to both the software developer and the customer. 

Other uses of this technology are found in the areas of software reuse and reengineering. 
In software reuse, complex reusable components can be retrieved from the software repository 
that contain more functionality than is required for the application. The desired functionality 
can be isolated using prototype slicing by taking the slice of the complex component with 
respect to the output streams desired. The resultant slice will contain any part of the complex 
component that affects the output stream. In reengineering, if a program written in some 
high-level language can be translated into the prototyping language, PSDL, then changes 
made to the prototype version of the base program can be automatically incorporated into 
the prototype versions of the target programs, and the resultant prototype can then be used 
to generate new production code for the reengineered program. 

A. RAPID PROTOTYPING 

Rapid prototyping is an approach to software development that was introduced to 
overcome the following weaknesses of traditional approaches: 

1. Fully developed software systems that do not satisfy the customer’s needs, or are 
obsolete upon rele2ise. 

2. No capabibty for accurately evaluating real-time requirements before the software 
system has been built. 

To overcome these weaknesses, computer-aided software development methods must be 
developed which ensure accurate requirements engineering and emphasize efficient change 
incorporation both during development and after fielding of the software system. Computer- 
Aided Rapid Prototyping is one such methodology. Rapid prototyping overcomes these 
weaknesses by increasing customer interaction during the requirements engineering phase 



of development, providing executable specifications that can be evaluated for conformance 
to real-time requirements, and producing a production software system in a fraction of the 
time required using traditional methods. Rapid prototyping allows the user to get a bet¬ 
ter understanding of requirements early in the conceptual design phase of development. It 
involves the use of software tools to rapidly create concrete executable models of selected 
aspects of a proposed system to allow the user to view the model and make comments early. 
The prototype is rapidly reworked and redemonstrated to the user over several iterations 
until the designer and the user have a precise view of what the system should do. This pro¬ 
cess produces a validated set of requirements which become the basis for designing the final 
product [Ref. 36]. The prototype can also be transformed into part of the final product. In 
some prototyping methodologies, prototypes are developed, demonstrated and then thrown 
away before the production system is developed. In prototyping methodologies like the one 
used in CAPS, the prototype is an executable shell of the final system, containing a subset 
of the system’s ultimate functionality. After the design of the prototype is approved by the 
customer, the missing functionality is added and the system is delivered. In this approach 
to rapid prototyping, software systems can be delivered incrementally as parts of the sys¬ 
tem become fully operational. Figure I.l shows the life-cycle model for this prototyping 
methodology. 

In this model, the customer provides a set of initial goals to the designer. The designer 
tcikes those initial goals and formulates a set of requirements from which the first version of 
the prototype is designed. This prototype is then demonstrated to the user, with the user 
providing feedback to the designer. The designer takes the feedback, adjusts the requirements 
to reflect the adjusted goals and makes whatever changes to the prototype necessary to 
satisfy the requirements. It is then redemonstrated to the user for more feedback. This 
iterative process continues until a validated set of requirements is accepted by the user. The 
designer then takes the prototype and implements the remainder of the functionality needed 
to produce the operational system. The result is an operational software system that satisfies 
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Figure 1.1: Rapid Prototyping Life-Cycle Model. [Ref. 20] 


the customer’s requirements and that is delivered in only a fraction of the time it would take 
using traditional software development methods 

Change-merging is an integral part of the rapid prototyping methodology. During the 
Design Prototype System phase of prototype development, multiple variations of a large pro¬ 
totype are likely to be developed. This can happen when different development teams are 
working on different aspects of a system, or when different possible solutions to a problem 
are explored in different ways. In the first example, it will certainly be necessary for the sepa¬ 
rately developed pieces of the prototype to be combined into a single system before execution 
for the customer. In the second example, the customer may desire a system containing some 
or all of the aspects contained in each solution. In this case, these different prototypes must 
be change-merged to capture the significant parts of each variation. Our change-merging 
method will allow these combinations to be done automatically, ensuring that the resultant 
prototype is semantically correct, with respect to all of the input variations. If the pieces are 
not compatible with regard to the semantics of the prototype, then our method will identify 
the parts of the prototype containing the conflicts. This technology encourages the designer 
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to explore different solutions to a problem, and to spread the development workload in a 
large project without concern for the subsequent integration of these independent efforts. 

B. PROTOTYPING SYSTEM DESCRIPTION LANGUAGE 

Our method has been implemented for use in the CAPS development system. It is 
designed to operate on programs written in the Prototyping System Description Language 
(PSDL), dissociated with CAPS. PSDL is a high level specification and design language which 
can be translated into executable code. 

PSDL is a generalization and extension of a data flow language, with the addition 
of control constraints and timing operations [Ref. 35]. A PSDL prototype consists of two 
parts: a specification and an implementation. The specification of a prototype contains 
the interface, and the implementation contains either a PSDL graph implementation, or a 
programming lemguage implementation. The PSDL graph implementation contains a set of 
operators, a set of data streams through which the operators communicate with one another, 
and a set of control and timing constraints which specify restrictions on the execution of the 
operators or data streams. The programming language implementation is written in any 
high-level programming language like Ada or C that is supported by the environment. 

All operators in PSDL prototypes are state machines. Since PSDL is, by definition, 
non-deterministic, the meaning of an operator in PSDL is a mathematical relation. PSDL 
operators with only one state, or an empty set of state variables, and only one possible out¬ 
come are functions. This meaning is defined by the operator’s possibility function discussed 
in a later section. 

A data stream in a PSDL prototype is a communications link between operators. Each 
data stream is either a data flow stream or a sampled stream. Data flow streams are FIFO 
buffers of lengths at least one. When a new value is written to the stream, it is appended 
to the buffer. Values are removed from a data flow stream only when they are read by the 
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consumer. Values on data flow streams can be read only once. Sampled streams are not 
traditional data flow streams. They have buffers of size one. When a value is written to the 
stream, it remains on the stream until a new value is written to the stream, at which time 
the old value is overwritten. A value is not removed from the sampled stream when read. 
Data streams can be written by more than one operator, and they can be read by more than 
one operator. A complete listing of the PSDL grammar is contained in Appendix D. 

C. OVERVIEW 

In the chapters that follow, we provide background information which we used to pro¬ 
duce a working change-merging tool. Chapter II provides definitions of mathematical con¬ 
structs used in later chapters. Chapter III provides information about related work, some of 
which was accomplished by others before our effort was started, and some we have accom¬ 
plished during the course of the resewch effort. Chapter IV provides a semantic model for 
the PSDL computational model which we used to develop our algorithm, and it contains the 
discussions about this dissertation’s primary contributions to the state of the art. Chapter 
V contains the algorithms used to implement our tool, along with a discussion of their cor¬ 
rectness and complexity. Chapter VI outlines the development of the change-merging tool 
and Chapter VII provides our analysis of what we accomplished in this effort, and some 
future research options in this area. There are five appendices: Appendix A contains formal 
specifications for the constructs used in our model, Appendix B contains details about the 
effect of PSDL control constraints on our model, Appendix C contains proofs considered too 
lengthy to be included in the text of the dissertation, and Appendix D contains a listing of 
the PSDL grammar, and Appendix E contains the program listings of our implementation. 
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II. ALGEBRAIC FOUNDATION FOR MERGING 


A. WHAT IS CHANGE-MERGING 

Change-merging is a process that allows different changes to a software product to 
be combined using computer-aided tools. The result of this change-merge must contain the 
differences between the base version and each input version, and must be correct with respect 
to the method used; syntactic or semantic. Syntactic change-merging is performed on the 
source code of the the input versions with respect to the differences in the syntax of each 
version. Semantic change-merging is performed on the functions computed by the software 
product with respect to the behavior associated with each input version. Semantic change¬ 
merging requires a solid mathematical foundation to provide some guarantee of correctness 
and engender confidence in a working change-merging system. As has been pointed out in 
much of the previous work on merging, there is a solid foundation for representing program 
variations in algebra [Ref. 6, 28, 42]. This chapter introduces and explains the mathematical 
concepts needed to imderstemd the work presented in later chapters. Section B describes 
the sets and partially ordered sets, and their relation to change-merging. Section C extends 
the discussion to Lattices and describes how lattices are used in change-merging. Section D 
builds up to Boolean and Brouwerian Algebras which are very useful in performing change- 
merge operations. 

B. SETS AND POSETS 

A set is a collection of objects, c2Jled elements. Operations on sets include £ (member¬ 
ship test), U (union), fl (intersection) and — (difference). A partially ordered set, or poset, 
is defined as follows [Ref. 16]: 
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Definition 1 Partially Ordered Sets 


A nonempty set X is said to be a partially ordered set, or poset, provided that a relation 
C is defined on X, satisfying the following: 

1. C is reflexive: a: C a: for all x € X; 

2. C is antisymmetric: x Oy and y C x imply that x = y, 

3. C is transitive: x C y and y C ar imply that x C x. 

Such a relation C is called a partial ordering of the set X. 

Our method of change-merging is performed on variations of a PSDL program. Changes 
to PSDL programs are not always extensions of a previously defined program. Different 
variations can change a previous program in different ways. Since these different variations 
are not always compatible extensions of earlier versions, the set of all program variations 
does not form a completely ordered set. But since some program variations are compatible 
extensions of other programs, the set of all program variations forms a partially ordered set, 
with respect to an approximation relation, C. 

Definition 2 Approximation Relation for PSDL Prototypes 

If X and y are two PSDL prototypes, x approximates y, written x C y, if y exhibits any 
behavior that x exhibits. 

Proposition 1 The set of all possible PSDL prototypes is a poset. 

Proof: 

If X and y are PSDL prototypes, let C be the approximation relation defined in Defini¬ 
tion 2. 

By Definition 1, for the set of all possible PSDL prototypes to be a poset, it must satisfy 
the three conditions, reflexivity, antisymmetry, and transitivity. 



(a) Clearly a: C i, as i certainly exhibits its own behavior. 

(b) Let xQy and y C x. Then y exhibits any behavior that x exhibits, and x exhibits 
any behavior that y exhibits. Thus x = y. 

(c) Let X Q y and y C 2 . Then y exhibits any behavior that x exhibits and possibly 
more, and 2 exhibits any behavior that y exhibits, so 2 exhibits any behavior that z exhibits. 
Thus z C 2 . 

Therefore by (a), (b) and (c), the set of all possible PSDL prototypes is a poset. □ 

C. LATTICES 

A lattice ordered poset is a partially ordered set (L, C) such that for every pair of 
elements, x,y £ L, the supremum, sup{x,y), and the infimum, inf{x,y), exist [Ref. 34]. An 
example of a lattice is shown in Figure 2.1. 

An algebraic lattice is a nonempty set L together with two binary operations, meet (PI) 
and join (U), which satisfy the following conditions for all x,y,z £ L [Ref. 34]: 

(1) Commutativity: i PI y = y PI z and z U y = y U z. 

(2) Associativity: z PI (y PI 2 ) = (z PI y) PI 2 and z U (y U 2 ) = (z U y) U z. 

(3) Absorption: z PI (z U y) = z and z U (z PI y) = z. 

(4) Idempotence: z PI z = z and z U z = z. 

In the context of merging pure program extensions, the meet (PI) operation represents 
the greatest common approximation of two programs, and the join (U) operations repre¬ 
sents the least common extension. The greatest common approximation of two programs 
represents the functionality common to both programs, and the least common extension 
represents the union of both of their functionalities. 
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Figure 2.1: An Example of a Lattice. 

According to [Ref. 34], every lattice ordered set is an algebraic lattice if we define 
a: n y = inf{x, y) and t U y = sup(x, y). 

A distributive lattice is an algebraic lattice for which at leaist one of the following 
properties holds: 

1. in(yUz) = (xny)U(xnz). 

2. a:U(ynz) = (a: U y) H (z U a:). 

An algebraic lattice C is complemented if for every x £ £, there is at least one element 
y € jC such that z U y = T and z fl y = J.. We say that y is the i complement of z. 

D. BOOLEAN AND BROUWERIAN ALGEBRAS 

A Boolean Algebra is a complemented, distributive lattice [Ref. 34]. Change-merging 
over Boolean algebras is done very simply using set operations. A very rich and well under¬ 
stood set of laws is available for the use of Boolean Algebras. 

A Brouwerian Algebra is a distributive lattice with a pseudo-difference operation, —, 
characterized by the property z — y C z z C y U z. This property states that the 
pseudo-difference of two sets z and y is contained in the set z if and only if z is contained 
in the supremum of y and z. A formal definition of Brouwerian algebr^ls follows [Ref. 39]: 
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Definition 3 Brouwerian Algebras 

A Brouwerian algebra is an algebra (L, U, D, —, T) that satisfies the following properties: 
(i) (i,U,n) is a lattice with a greatest element, T. 

(a) L is closed under —. 

(Hi) For all elements x,y,z € L, the formulas x — y C z and x CyU z are equivalent. 

[Ref. 39] also provides the following properties of Brouwerian algebras: 

Theorem 1 Let L be a Brouwerian algebra under U,n and —. Then: 

(i) L has a zero element, J. determined by the formula ± = T — T. 

(a) L is a distributive lattice. 

(Hi) If X Cy, then x-zCy-z,z — yCz-x, and T - y CT — x. 

(iv) xCy <=!> x-y = ±. 

(v) xCy^j{x-y). 

(vi) {xUy)xLyQ X. 

(vii) x-zC{xUy)-z. 

(viii) zU {x - y) = z ->r[{zU x) - {zU y)]. 

(ix) z-{xr\y) = {z-x)\J{zL y). 

(x) {xUy)-z = {x-z)\J{y-z). 

(xi) T - (T - x) C X. 

(xii) T - (T - (T - x)) = T - X. 

(xiii) T - ± = T and T - T = J.. 
rxir;;xU(T-x) = T. 

The proof of this theorem is contained in [Ref. 39]. 

Brouwerian algebrsis are very useful in the study of sets in which the true difference 


between two elements is not guaranteed to ej 




E. SUMMARY 


It turns out that every component of PSDL programs that can be change-merged can 
be modeled using lattices or algebras. Many of the different parts of PSDL prototypes which 
are merged separately do not fit nicely into Boolean algebras, with the exception of some 
control constraints, so we introduced the concept of Brouwerian algebras. Throughout this 
dissertation, the concepts discussed in this chapter are used to prove different parts of the 
change-merging model contained in Chapters III and IV, and considered in the development 
of the algorithm and implementation. 
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III. RELATED WORK 


This chapter reviews and assesses some of the work related to the change-merging 
problem which has already been accomplished. Since change-merging is a relatively new 
problem, there have been a number of research efforts aimed at defining the theoretical 
foundations for the problem, but not much effort has been placed on implementing a solution 
for real programs. Our research effort is the first to tackle a real-world problem and succeed 
in providing a working solution. This effort would have been nearly impossible, however, 
had it not been for the pioneering work reviewed in this chapter. 

A. TEXT BASED MERGING 

The earliest work on program merging relied on combining changes made to the text 
files containing the source code for the program [Ref. 43, 45]. These early systems certainly 
provided an advance to the then-current state of the art, but syntax-based merging did not 
prove useful in the general Ccise, cis syntax-baised merging proved insufficient to provide any 
guarantee of semantic correctness [Ref. 6]. 

The first of the text-beised merging systems was introduced as part of a software man¬ 
agement toolkit called the Revision Control System or (RCS) [Ref. 45]. This system was 
developed as a way to maintain the update history of a file. The system saves the initial 
version of the file when invoked for the first time and, in subsequent invocations, saves only 
the changes made to the previous version. Merging is accomplished through the use of the 
command RCSMERGE. RCSMERGE tries to combine the differences between two differ¬ 
ent changes to the same base document based on the assumption that changes to disjoint 
portions of the text are independent. Where it is able to combine the changes, it makes 
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the change to the output file. When it is not able to combine the differences, it prints the 
respective piece of each version as a conflict in the output file, so the author can resolve it 
manually. 

These systems work well for most text files with small individual changes. For programs, 
however, they do not provide even a guarantee of syntactic correctness, and in some cases 
when the changes are significant, the tool is unable to match even the parts that did not 

B. MERGING OF PROGRAM EXTENSIONS 

In [Ref. 6], Berzins presents the first definitive work on semantic-based program merging. 
This work is limited to considering program extensions, and does not consider changes that 
remove functionality from the base program. It recognizes that program extensions can be 
ordered using an approximation relation C. If p is a base program, and q is an extension of 
p, then p E g. That is to say that the functionality of q agrees with the functionality of p 
everywhere p is defined, but q may be defined where p is not. 

With this ordering in mind, two programs p and q can be merged by finding the hast 
common extension of p and q, written pUg, where p and g are base programs and pUg is the 
merged program. He also recognizes that the exact least common extension of two programs 
is not computable in the general case, but a safe approximation is sufficient in practice. 

Berzins considers four software domains: specifications, functions, programs and data 
types. These domains are defined in Figure 3.1. All of these domains are represented using 
lattices. The following sections describe the representation of these domains. 
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Specification: Defines Acceptable Range of Behavior ' 

Function: Models Actual Behavior 

Program: Algorithms Defining Partial Functions 

Data Type: Set on which Programs Operate 

Figure 3.1: Definitions of Relevant Domains 

1. Functions, Specifications and Programs 

Functions, specification and program domains can all be viewed as lattices with 
respect to the approximation ordering C. Each lattice contains the elements of the domain 
together with a top element, T, representing an overconstrained element, and a bottom 
element, X, representing an undefined element. The least common extension of two elements, 
X and y can then be defined in terms of lattice operations as the least upper bound of x and 
y, denoted x U y. If x and y are compatible, then x U y 5 ^ T, otherwise x U y = T. 

2. Data Types 

The lattice for a domain representing a conventional data type, Dq, can be defined 
as a set D = ZloU{-L, T}, where X approximates everything and T is an extension of 
everything. The definition of the extension relation for V is: 

X C y <=» (X = x) V (x = y) V (y = T) 

The least upper bound of any two unequal elements in this domain is T, the overconstrained 
element. This model applies to data types whose elements are either completely defined or 
completely undefined. An example of a type that is not covered by this construction is a list 
with a component selector implemented using lazy evaluation. Some components of such a 
list may be well defined, while other components may be undefined (i.e. cause infinite loops 
if they axe accessed). 
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3. Analysis 


The work presented in [Ref. 6] provides a fundamental basis for most of the current 
work in semantics-based program integration and merging. It looks at programs in terms of 
their semantic building blocks and provides a theory describing how merging occurs at the 
building block level. This work shows that computing a useful approximation to an ideal 
merge is both achievable and sufficient. 

C. INTEGRATION OF CHANGES TO WHILE-PROGRAMS 

In [Ref. 28], the first semantics-based algorithm for integrating two non-interfering 
modifications of a base program is described. This integration algorithm produces a third 
program which reflects both modifications, and uses program dependence graphs (PDGs) to 
abstractly represent the programs. Using program slicing, it then determines which portions 
of the two modifications are different from the betse program. B 2 ised on this information, 
the algorithm uses a conservative approximation to determine if the changes can interfere. 
If they can not, the program slices are combined into one integrated PDG, which is then 
transformed into a final version of the integrated program. 

1. Program Dependence Graphs 

A PDG for a program P, as described in [Ref. 28], is a directed graph, Gp, with 
vertices representing statements in the program, and edges representing control and data 
dependencies between the vertices. There are also two special types of vertices in the PDG 
which are not program statements; an entry vertex and a final-use vertex for each output 
variable. A complete list of the types of vertices is contained in [Ref. 28]. 

Using these components, a PDG can be constructed for any while-program [Ref. 33]. 
Figure 3.2 shows an example of a simple program and its associated PDG. By analyzing the 
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parts of this graph that affect a certain variable, we are able to observe the effects of a change 
to the program with respect to that variable. This is done using program slicing {Ref. 47]. 



DEF-ORDER 
LOOP CONTROLLED 


Figure 3.2: Example of a Program Dependence Graph [Ref. 28] 

2. Program Slicing 

The program slice of a graph G with respect to a vertex s is the subgraph of G 
induced by all vertices that can reach s by way of control (—*^) or flow (—>y) dependence 
edges, along with the edges that connect the vertices. 

V{G/s) = {we V{G) \w^.s} 

To get the slice of a graph G with respect to one of the output variables, say i, 
merely take the slice with respect to the vertex labeled FinaLUse{x). The slice is con¬ 
structed backward from the final-use vertex, and includes all control or flow edges which 


17 






can contribute to the final value of x. Def-order edges are contained in the slice only if the 
vertex which observes the dependency is also included in the slice. This construction can 
be extended to a set of vertices S = {sj, S 2 ) •S]} by taking the union of the vertex and 

edge sets of all of the individual program slices. Figure 3.3 shows an example of the slice 
of the previous program taken with respect to the variable x at the final-use node and the 
corresponding PDG. 



CONTROL 

LOOP INDEPENDENT 

DEF-ORDER 

LOOP CONTROLLED 


Figure 3.3: Example of a Slice of a Program Dependence Graph [Ref. 28] 

3. Integration Algorithm 

The integration algorithm presented in [Ref. 28] starts by creating program depen¬ 
dence graphs for each program 2 uid, using program slicing, identifies the part of the base 
program which is preserved in all three versions and the parts of the variations which are 
different from the btise. The common part of all three versions is called the preserved part, 




and the part of each variation that is different from the base is called the affected part of 
that variation. 

These three slices are then combined into an integrated PDG. If the integrated 
PDG is feasible’ and the two variants do not interfere with each other, then the integration 
is successful. One major problem identified in this work is that determining whether a PDG 
is feasible is NP-Complete [Ref. 28]. The other criterion for determining success is more 
tractable, that of determining interference. This is done by comparing the slices of each of 
the three original versions against slices in the merged version. If the slice of the merged 
version with respect to the affected parts of each modification is the same as the slice of that 
modification with respect to its affected parts, and the slice of merged version with respect 
to the preserved part is the same as the base version with respect to the preserved part, then 
the versions do not interfere, and a successful integration is possible. 

The work in [Ref. 28] is supported by three theorems; the slicing theorem, the 
equivalence theorem and the integration theorem. The slicing theorem states that when 
given the same input and starting state, a slice of a program that halts produces precisely 
the same output as the program. The equivalence theorem states that if two programs have 
equivalent PDGs, then the programs are themselves equivalent. The integration theorem 
states that if M is the result of a successful integration, then M halts on any initial state 
on which the three input versions halt, and M correctly preserves the meaning of each 
modification to the base. 

4. Meaning Functions 

Meaning functions [Ref. 33] represent the semantic meaning of a program as map¬ 
pings from states to states. These state changes are represented as sets of pairs including an 
initial state and the corresponding final state(s). In [Ref. 10], Berzins provides a theoretical 
‘A program dependence graph is feasible if it is a PDG for a program.[Ref. 2^ 
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foundation for merging simple, imperative programs using their meaning functions. This 
theory uses the notion that program variations can be viewed eis partial functions modeled 
using a powerset lattice. Since a powerset lattice is equivalent to a Boolean algebra, normal 
set operations, U, D and — can be used to reason about these program variations. 

This theory shows that a change transformations from a base program / to a 
variation g, A[f,g], can be applied to a second variation h, A[/,5](/i) with precisely the 
same results as if the change from f to h were applied to g, A[/, h]{g). This is very useful 
in change-merging, as it demonstrates that independent updates to a common base version 
5 of a software product and subsequently change-merged without regard for the order in 
which they were accomplished. As long as the changes made are compatible, the results in 
terms of the meaning functions are the same. It does show, however, that the change-merged 
program does not necessarily have to be similar to the input programs. 

The meaning functions for the programs shown in Figure 3.4 are as follows: 
m{B) = (X > 0 {((x,!,),(x,l))} I X < 0{((x.j,), (x,-l))}) 

m(A) = (x > 0 - {((x,y),(x,l))} | x < 0 {((x,y),(x,0))}) 

m(C') = (x > 0 — {((x,y),(x,x))} | x < 0{((x,y),(x,-l))}) 

These three versions are merged using their meaning functions as follows [Ref. 10]: 
m(M) = m{A\B]C) = m(A)[m(B)]m(C') * 

= (m(A) - m(5)) U (m(A) n m{B)) U (mCC) - m(B)) 

= (x>0-»{((x,y),(x,l))}-{((x,y),(x,l))}| 

^ < 0 {((x,y),(x,0))} - {((x,y),(x,-l))}) 

U(x > 0 ^ {((x, y), (X, 1))} n {((x, y), (x,x))} j 

X < 0 {((x,y),(x,0))} n {((x,y),(x,-l))}) 

U(x > 0 {((x,y),(x,x))} - {((x,y),(x,l))} j 

X < 0 {((x, y), (x, -1))} - {((x,y), (x, -1))}) 

*The notation A[B]C will be introduced in Section D.l 
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= (x>0^{} |z<0-.{((x,j,),(x,0))} 

U(x>0--{((x,3/),(l,l))} |x<0-.{}) 
U(x>0-.{((x,y),(x,x))|x^l}|x<0-{}) 

= (X > 0 - {((x,y),(x,x))} I X < 0 {((x,y),(x,0))}) 

= m(if X > 0 then y.— x else y := 0) = m(M) 

Base version B: if x > 0 then y := 1 else y 

First change version A: if x > 0 then y := 1 else y 

Second change version C: if x > 0 then y := x else y 

Figure 3.4: A Program and Two Variations [Ref. 10] 

5. Analysis 

The work presented in this section shows that a method can be developed for 
integrating real programs. The work contained in [Ref. 28, 29, 48] illustrates a method for 
integrating programs in a simple imperative progreimming language that has been developed 
and works. This demonstrates that a practical method is possible for imperative programs, 
but falls short of providing a method which is useful to solve any real world problems. In 
particular, the method fails to provide any sort of conflict location or resolution. If a conflict 
is detected, then it is reported to the user, and the integration fails. It is up to the user to 
determine the nature of the conflict and how it should be resolved. Our methods address 
these problems as shown in the next section and in Chapter IV. 

D. CHANGE-MERGING OF PSDL PROGRAMS 

In [Ref. 20], an initial attempt at developing a model for change-merging PSDL pro¬ 
grams is presented. Although crude, this model provides us with an important part of the 


:=-l fi 
:=0fi 
:= -1 fi 
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specification change-merging model, and insight into the current effort defined in subsequent 
chapters. 


1. Change-Merge Operation 

This change-merge operation is defined by the operation A[B\C, where A, B and C 
are sets of pairs representing the functionality of three different versions of a PSDL program. 
The operation A[B]C was initially introduced by Berzins in [Ref. 9] and is defined as: 

A[B\C = (yl - B) U (A n C) U (C - B) 

where fl, U and — represent the greatest common approximation, least common extension, 
and semantic difference respectively, between two programs. 

The set of all PSDL programs, together with a T and J., forms a lattice using the 
relation approximates [Ref. 20]. If ^4 is an extension of B, then we say that B approximates 
A, written B C v4. The T element in the lattice is an extension of every PSDL program, 
and the ± element approximates all PSDL programs. For example consider the lattice in 
Figure 3.5. In this example, O and P are extensions of A and A approximates both O and 
P. P and Q are both extensions of B and B approximates both P and Q. B is a common 
extension for both A and B. In fact, P is the least common extension of A and B. 
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The least common extension of two PSDL programs, AUB, is the smallest possible 
PSDL program P such that P and B ^ P, and represents the union of the functionalities 
found in both A and B. In Figure 3.5, P is the least common extension of A and B. The 
greatest common approximation of two PSDL programs, Pr\Q, is the largest possible PSDL 
program B such that B Q P and B CQ, and represents the common functionality found in 
both P and Q. In Figure 3.5, B is the least common extension of P and Q. The semantic 
difference between two programs, A — B, represents the functionality found in A, but not in 
B. The semantic difference exists if the lattice is a Boolean algebra, and a pseudo-difference 
can be defined if the lattice is a Brouwerian algebra. 

It has been shown that the least common extension of two programs is not com¬ 
putable in the general case [Ref. 6]. In [Ref. 20], we demonstrated that an approximation that 
is computable is sufficient to provide a useful change-merge for most cases. The following 
sections outline the model defined in [Ref. 20]. 

2. Interfaces 

The interface of a PSDL operator P is the definition of the operator’s external 
contacts. It defines Ip, the set of inputs expected by the operator, Op, the set of outputs 
that can be expected, and in the case of generic templates, GNp, the set of generic param¬ 
eters used to instantiate the prototype. Ip, Op, and GNp are all ordered sets (sequences). 
The interface may also contain a set Stp, of internal state variables, a set Ep, of possible 
exceptions, and a maximum execution time constraint that is met by the program. Stp and 
Ep are sets. 


a. Sequences 

Sequences are a significant building block for many programming languages, 
including PSDL. A sequence is a totally ordered collection. Since the order of the collection 
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is significant, any change made to the sequence is an incompatible change and creates a 
sequence which is neither an approximation nor an extension of the original sequence. A 
correct mathematical representation for a sequence would be a flat lattice, like the one in 
Figure 3.6. This means that the only approximation for the sequence is the undefined 
sequence, ±, and the only extension of the sequence is the unconstrained set, T, and the 
greatest common approximation of any two sequences is the undefined element, ±. 



Figure 3.6: A Flat Lattice Representation for a Sequence 

(1) Input and Output. Input and Output interfaces are sequences of input 
and output streams. The order of these sequences is significant because actual parameters 
are cissociated with formal parameters based on the order in which they appear. In change¬ 
merging Ia, Ib, and into Im, any change between the interface sequence of the base 
version and the two modified versions is significant, and must be preserved in the change- 
merged version. The change-merged sequence of inputs, or outputs, is determined by the 
following rules: 

1. If both of the modified versions have the same interface sequence as the base, 
then: Im = /b„„. 

2. If one of the two modified versions, say Ia, is the same as the base, and Ib is 
not, then: Im = Ib- 

3. If aU three versions are different from each other, then: Im = T. 
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The first situation is the case in which no changes were made between the 
inputs of the Base and the two modifications. In this case, the change-merged version should 
have all of the same inputs, or outputs. The second situation is the case in which only one of 
the modifications changed from the bcise. In this case, the change from the base is significant 
and must be preserved in the change-merged version. The third situation is the case where 
both of the modifications changed from the bcise. The result is a conflict because there 
is no proper PSDL specification that is consistent with both modifications. The result of 
a change-merge which produces a conflict for this situation would be an input declaration 
which contains a T where the input stream declarations would be. 

The type declarations of the streams also have to be merged. Because the 
types are significant, any change to the type declaration must be preserved in the merged 
version. Types are also change-merged using a flat lattice structure. Figure 3.7 contains an 
example of a change-merge on Input Sets. 


Ssa.. = INPUT 

X : integer, 
y : real 
OUTPUT 


Sa = INPUT 

X : integer 
OUTPUT 
10 : integer, 
t : integer, 
z : string 

Sm = INPUT 

X : integer 

OUTPUT 


Sb = INPUT 

X : integer, 

OUTPUT 
w : integer 


Figure 3.7: Example of a Change-Merge on Input Sets [Ref. 20] 
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(2) Generic Parameters. The Generic interface is contained only in template 
operators and PSDL type specifications. Template operators are operators in the Software 
Base used to instantiate software components. Change-merging generic parameters is similar 
to change-merging input and output parameters with the exception that, in addition to 
value parameters, generic parameter sequences may also contain operator parameters and 
type parameters. Changes to generic sequences follow the same rules as Input and Output 
sequences. Figure 3.8 shows an example of a change-merge operation on generic parameters. 


GNb^sc = GENERIC 
fl : type, 
t2 : type, 

ol : operation[il,i2 : tl,ol : <2], 
vl : integer 

GNa = GENERIC GNb 

<1 : type, 
t3 : type, 

o2 : operation[il : <l,ol : f3], 
nl : integer 

GNm = GENERIC 
tl : type, 

<3 : type, 
o2 : operation[il : fl,ol : <3], 
nl : integer 


= GENERIC 
<1 ; type, 

<2 ; type, 

ol : operation[il,i2 : <l,ol ; t2], 
vl : integer 


Figure 3.8: Example of a Change-Merge on Generic Parameters [Ref. 20] 


b. Sets 

Sets are modeled using a “Powerset Lattice” as shown in Figure 3.9, and thus 
more freedom can be exercised in change-merging them. Change-merge operations do not 
follow the same rules for sets <is for sequences. 
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{a,b,c] 



{] 

Figure 3.9: A Powerset Lattice Representation for a Set Containing Three Elements 

(1) States. State variables differ from input and output variables in that, 
abstractly, they are tuples, containing a name, a type and an initial value. As the set 
of state variables is unordered and invisible to the rest of the program, the state set can 
be increased or decreased without affecting the parts of the program outside the modified 
component. In change-merging state variable sets, the operations FI, U, and — are equivalent 
to the corresponding set operations, U, FI and —. The third part of the tuple, the initial 
value, requires an additional check in the change-merging process. These initial values are 
ordered using a flat lattice, because they are ordinary data values. The initial value of a 
change-merged state variable follows the same change-merging rules as input and output 
variables. If eJl three versions have different initial values for the same state variable, then 
the change-merged version contains a T in the place where the initial value is assigned. If 
only one of the modifications aissigns a different initial value than the base version, then the 
change-merged version contains the initial value of the one that was different. 

(2) Exceptions. The exceptions interface is a list of identifiers which denote 
exception values which may be returned by the operator. Consequently FI, U, and — can be 
interpreted as the corresponding set operations, U, FI and —. Exceptions that appear in one 
or both of the modified versions, and not in the base, appear in the change-merged program. 
Exceptions that appear in the base and do not appear in at least one of the modifications 
are not included in the change-merged program. 
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(3) Maximum Execution Time. Maximum Execution Time (MET) is the 
only timing constraint that appears in PSDL specifications. MET is the maximum Ci’U 
time that an operator can use to perform its assigned task. Change-merging two MET 
constraints, and <2, can be done as follows: 

<iUf2 = min{tuh) 

<int2 = mai(fi,t2) 

t\ -t-i = if < ti then oo else tj 
T =0 
± = oo 

Proposition 2 The set of METs form a Brouwerian Algebra 

Proof: 

Let M be the set of all possible METs. 

We must show that A<,U,n is a distributive lattice, that M. is closed under —, and 

that 

Vo, b,c e M,a — b < c o < (6U c). 

1. {M, U, n) is a distributive lattice: 

Clearly, a LI 6 and o D 5 exist for any a,b £ M, and the reflexive, antisymmetric, and 
transitive properties hold, so (^,LJ,n) is a lattice. 

M is distributive: Let a,b,c £ M. We use a table to illustrate: 



an{bUc)\ 

(o n 6) u (o n c) 

a<b<c 

b 

b 

a<c<b 

c 

c 

b<a<c 

a 

a 

b<c<a 

a 

a 

c<a<b 

a 

a 

c <b < a 

a 

a 


From the table it is easy to see that M. is distributive. 

2. M is closed under —: 

Since o — 6 is always either o or oo for any o and 6, M. is certainly closed under —. 
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3. For any a,b,c £ M, a — b < c a < (6 U c): 

Assume a — b < c. Then, a < b, since otherwise, a ~ b — oo. Since a < b, then a < c. 
Thus, (2 < (6 U c). 

Now, assume o < (6 U c). Then a < b and a < c, and a — b = a. Thus a — 6 < c. 

Therefore, Ad is a Brouwerian Algebra. 

3. Functionality 

The functionality of an operator specification is a description of the behavior of an 
operator. It consists of a set of keywords, an informal description, and/or a formal descrip¬ 
tion. Through the use of keywords, the operator can be distinguished from other operators 
in the database during the retrieval process. Informal text descriptions are provided for use 
by the engineer. Formal axiomatic descriptions are provided to support automatic retrieval. 

The set of keywords can be change-merged using the appropriate set operations, 
U, n, and —. The informal description is a sequence and must be changed-merged using 
the same method described for input and output parameters. Formal descriptions can be 
change-merged using the Boolean algebra structure of the logic in which they are expressed: 

lUy = XVy 
X n y = X A y 
X - y = X A ->y 

4. Data Flow Graphs 

In [Ref. 20], a PSDL implementation graph for an operator A is viewed as a graph 
Da = {0,L}, where O is a set of vertices that represent the component operators of A, 
including the constant operator EXT representing external contacts, and where L is a set of 
links (labelled edges) which represent the data streams entering and leaving the elements of 
O. The labels for the links are the names of the data streams they represent. 
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The change-merging operation on PSDL data flow graphs is defined in terms of a 
bipartite graph Ba = {V,S,LI,LO}, where V is the set of operators in Da, 5 is a set of 
vertices which represent the data streams of operator A, LI is a set of edges from a stream 
vertex to an operator vertex, representing input links, and LO is a set of edges from an 
operator vertex to a stream vertex, representing output links. 

Change-merging the data flow diagrams is done by change-merging the graphs 
dBase, Ga and Gb hy subsets V, S, LI and LO. The operations U, H, and — can be 
interpreted as the corresponding operations U, fl, and —. This change-merge is accomplished 
using the following equation: 

Gm = \Ga — GBase] LI [Ga n Gb] LI [Gb - Gsose] 

This equation defines a structural or syntactic change-merging operation that does not nec¬ 
essarily correspond to a semantic change-merging operation. 

The greatest common approximation is obtained for the Base and the two mod¬ 
ifications by taking the intersection on all components of the graph. Then these common 
components are added to the disjoint components of each modification by subtracting out 
the parts of the two modifications which are also in the base. This operation preserves the 
parts of the program common to all the versions, while ensuring that significant changes 
made by the two modifications are included in the change-merged graph. 

This method of change-merging the implementation graph of a PSDL program 
fails to adequately consider the semantic effects of the changed modifications, as does the 
approximate method shown later in this chapter. Although these methods produce a change- 
merge that is useful in some cases, they are not nearly as useful as the slicing method 
described in Chapters IV and V. 




5. Data Streams and Control Constraints 

a. Data Streams 

A set of data stream declarations DSa, defines local data streams that are used 
only within the implementation of a composite operator, A, and that are not defined in the 
specification. The order in which the declarations appear is not significant. They have the 
same structure as exception declarations, and can be change-merged using the same rules. 
If a stream appears in DSBatc then it appears in DSm if and only if it appears in both DSa 
and DSg. If a stream does not appear in DSsaaci then it appears in DSm if and only if it 
appears in at least one of the sets DSa ^^nd DSb- These rules are: 

X € DSBaat A a: € DSa A a: € DSb xe DSm 

X € DSbcimc a -'(x € DSa A x € DSb) =► ”'(2^ G DSm) 

-i(x € DSbgsc) a (x G DSa V x G DSb) =>■ x € DSm 

-i(x G DSBaat) A -'(x G DSa V x g DSb) “’(a: G DSm) 

The type declarations of data streams are also significant, as with Input and 
Output Streams, and changes to those declarations must be preserved in the merged version. 
The type declarations can be merged using a flat lattice structure just as the Input and 
Output streams are merged. 

b. Control Constraints 

Control constraints are a set of pre-conditions, which control the firing of par¬ 
ticular components, and post-conditions, which filter the output provided by those compo¬ 
nents. The control constraints appear in the change-merged operator according to the same 
rules as the data stream definitions. Any control constraint that appears in all three input 
versions in exactly the same way appears in the change-merged operator without change. 
Any constraint which appears in one or both of the modifications, but not in the base. 
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appears unchanged as long as the conditions of the constraint are the same. Changes in con¬ 
ditions are handled differently depending on the type of constraint. Input and output guards, 
conditional exceptions, “TRIGGERED IF”, “OUTPUT IF”, “EXCEPTION IF”, and timer 
operations have logical predicates as conditions. Timer operations are not change-merged 
as straightforwardly as other predicate constraints. Different operations exist for different 
activities. Start, stop, and reset are the three timer operations used in PSDL. The timer 
operations affect the state of the timer. The start and stop operations affect the run state of 
the timer, and the reset operation affects the value state of the timer. The reset operation 
is thus independent of the others, and can be merged independently. If a reset operation 
appears in all three versions, or appears in at least one of the modifications, but not in the 
base, then it appears in the changed merged version as well. The start and stop operations 
must be change-merged using a flat lattice ordering relation, as with inputs and outputs. 
The predicates that accompany the control constraints are change-merged according to the 
usual rule, A[Base]B = {A- Base) U (i4 FI B) U (B - Base), where the operations FI, U, and 
— are interpreted as follows; 


aU6 ^ aV6 
ant =}> ahb 
a-b =► a A-'6 

The constraints “PERIOD”, “FINISH WITHIN”, “MAXIMUM RESPONSE 
TIME”, and “MINIMUM CALLING PERIOD” have integer values as conditions. These 
values are ordered using a flat lattice and can be change-merged as follows. For “PERIOD” 
constraints, if the value is the same in all three input versions, then it appears unchanged 
in the merged version. If it is different from the b2ise in one of the modifications and the 
same as the base in the other modification, then the change must be preserved and the value 
appearing in the modification where it is different appears in the merged version. If all three 
versions have different values for the period, then a ± or undefined value appears in the 
merged version, indicating an unresolvable conflict. “FINISH WITHIN” and “MAXIMUM 
RESPONSE TIME” constraints are upper bounds and can be change-merged using the 
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same method described for “MAXIMUM EXECUTION TIME”. “MINIMUM CALLING 
PERIOD” is a lower bound and two MCP constraints, ti and t-2, can be change-merged 
using the equations shown below: 

t, Utj = mai(t,,t2) 
tiHij = min{U,t2) 

<,—<2 = if <2 > <1 then oo else ti 
T =0 
X = oo 

Proposition 3 The set of all MCPs form a Brouwerian Algebra 
Proof; See the proof of Proposition 2. 

6. Analysis 

The work presented in [Ref. 20] was a first look at providing a change-merging ca¬ 
pability for PSDL prototypes. It explored some critical issues in the problem and provided 
valuable information for work presented later in this dissertation. The work on change¬ 
merging specifications has proven to be very valuable and remains virtually unchanged in 
the current model. Only the parts of the model concerning timing constraints have been 
improved in the current model. The work on change-merging implementations was unsuc¬ 
cessful in providing a useful method. The next sections provide a look at an improvement 
over this method. 

E. CHANGING PSDL PROTOTYPES 

In [Ref. 21], another attempt at formulating a model for representing PSDL implemen¬ 
tations is explored. In this model, PSDL prototypes can be considered iterative versions 
of a software system. If S is the intended final version of the software system, then each 
successive iteration of the prototype can be viewed as an element of a sequence Si where 
limi_oo Si = S. 
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1. Prototypes cis Graphs 


Each prototype implementation Si is modeled cis a graph G; = {Vi,Ei,Ci), where: 

• V; is a set of vertices. Each vertex can be an atomic operator or a composite 
operator modeled as another graph. 

• Ej is a set of data streams. Each edge is labelled with the associated variable 
name. There can be more than one edge between two vertices. There can also 
be edges from an operator to itself, representing state vjiriable data streams. 

• Cj is a set of timing and control constraints imposed on the operators in version 
i of the prototype. 

2. Changes to Graphs 

The prototype designer repeatedly demonstrates versions of the prototype to users, 
and designs the next version based on user comments. The change from the graph repre¬ 
senting the ith version of the prototype to the graph representing the (i + l)st version can 
be described in terms of graph operations by the following equations: 

. Si+i = Ei+„ Ci+i) = 5i -f A5i 

• A5i = {yAi,VRuEAi,ERi,CAuCRi)yiheK-. 

•• ^i+i — = VAi'. The set of vertices to be added to Si- 

•• Vj — Vj+i =VRi: The set of vertices to be removed from 5;. 

•• £'1-1-1 ~ £i = EAi: The set of edges to be added to Sj. 

•• Ei — Ei+i = ERi'. The set of edges to be removed from Si- 

•• Q-i-i — = CAi'. The set of timing and control constraints to be added to 

£i- 

•• Gj — Gi+i = CRi: The set of timing and control constraints to be removed 
from Si- 
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5i+i = 5; + A5'i is defined in terms of the individual components of 5;+! as follows; 
Vi+i = ViV^VAi-VRi 
= £; U EA\ — ER\ 

Ci+i = Ci U CAi - CRi 

The following figures show an example of a change made to a composite operator in 
PSDL. Figure 3.10 contains a graph representation for a composite operator Opl consisting 
of 4 vertices and 6 data streams. Figure 3.11 shows a change to be applied to Opl to produce 
Op2. Figure 3.12 shows a graph representation of Op2, the result of applying the change to 
Opl. 
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Opl = {VuEuCi) 

Vi = {A,B,C,D) 

E, = {{X\:EXT-^A),{X2-.A-^B),{XZ-.A-^C),{XA:B-^D), 

(A'S : O - D), (X6:D-* EXT)} 

Cl = {maa:.eiec_fime(B, 100ms)} 


Figure 3.10: Example of a composite operator in PSDL 
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A^Opl = {VRa,VAa,EAa,ERa,CAmCRa) 
VAa = {E} 

VRa = {C7} 

EAa = {(X3:A-yE),(X7:E-^n)} 

ERa = {(X3 :A->C), (X5:C-^ D)} 

CAa = {Iatency{X7, E, D,50Tns)} 

CRa = {} 


Figure 3.11: Example of a change made to a composite operator in PSDL 
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Operator Op2 = Opl + A^Opl 


Op2 = {V2,E2,C2} 

Vj = {A,B,D,E] 

El = {{XI : EXT-* A),(X2: A-> B),{X3: A-> E),{XA-. BD), 
{X7:E^ D), {X6:D^ EXT)} 

Cl = {mai-exec.ttme(S, 100ms), latency{X7, E, D, 50ms)} 


Figure 3.12: Example of the changed operator 
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F. AN APPROXIMATE METHOD FOR CHANGE-MERGING 
PSDL PROTOTYPES 

1. Method 

In [Ref. 21, 23, 25], an approximate method for change-merging PSDL prototypes 
is explored. This method is useful in providing a rough approximation to the ideal change- 
merge, but was abandoned in favor of the more useful (and provably correct) slicing method 
[Ref. 23, 24]. It is included to record the effort expended in this endeavor. 

Recall the merging function introduced in [Ref. 9], and reintroduced in section D: 

M = A[B]C = (A - B) U (A n C) U (C - B). 

If the semantic function of a program is represented as a set of pairs, then two compatible 
modifications of a semantic function can be merged using this equation. 

In this equation, the union, intersection and difference operations are defined as 
normal operations on sets. The difference operation, (A — B) for example, yields the part 
of the function present in the modification, but not in the base version. The intersection 
operation yields the part of the function preserved from the base version in both modifi¬ 
cations. This model preserves all changes made to the beise version, whether extensions or 
retractions. In this model, two changes conflict if the construction produces a relation that 
is not a single valued function. 

In this section, we outline an approximate method for merging prototypes using 
the change model described in the previous section and the above definition. This method is 
approximate, in the sense that the change merging construction is applied to the structure 
of a PSDL program rather than to the mathematical function it computes. This method 
is simple, corresponds to common programmer practice, and produces semantically correct 
results most of the time. 
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The approximate method can be understood as follows. All PSDL implementations 
are graphs, whose structure roughly models their functionality. We have represented these 
graphs using sets. Different variations of a prototype are the results of different changes 
being applied to a common base version. We can merge the two new versions A and C by 
applying the change that produced A from B to version C, or by applying the change that 
produced C from B to version A. The result is the same in either case. Earlier, we expressed 
the (i + l)st iteration of a software prototype as Si+i = Si + ASi- Let us consider an ith 
version which has been changed in two different ways, via and As. The results of these 
two changes are denoted as Sa and Sb , respectively. Now let us consider a Ccise where the 
(i + l)st iteration is the result of merging these two changes; 

= 5x[5i]5B = {Sa - Si) U {Sa n Sb) U {Sb - 5;) 

The components of 5i+i; Vj+i, Ej+i and Ci+i can be computed similarly: 

Vi+i = VA[Vi\VB = (Vx-vi)u(VxnVB)u(VB-Vi) 

= EA[Ei]EB = {EA-Ei)U{EAnEB)U{EB-Ei) 

Ci+I = Ca[C-^Cb = - C7i) U n Cb) u (Cb - Ci) 

To demonstrate the concept of the merging operation, we provide the following 
example: The bcise prototype is as in Figure 3.13. Change A is outlined in Figure 3.14, with 
the result shown in Figure 3.15. Change B is outlined in Figures 3.16 and 3.17. The merging 
operation is performed in Figure 3.18 and the result is shown in Figure 3.19. 

The merge operation outlined in Figure 3.18 involves determining the real effect of 
changes made to the base, and any conflict that may arise due to similar changes between the 
two variations. This is a simple example illustrating the merging of two changed prototypes 
which do not conflict with one another. In some cases, two changes to a prototype can 
conflict with one another, and the result of their merging can be an inconsistent program. 
In such cases, the engineer must resolve the conflict off-line. 
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AAFishies 


VAa, VRa, EAa,ERa, CAa, CRa 


VAa = {Monitor_BacteriaJjevel,ControLWaterJ'lovDJ2, DisplayJStatusJl} 
VRa = {Control.Wate.rJ'low, Display Status) 

EAa = {{BacteriaStatus : MonitorSacteria-Level —* ControLWaterJ'low^), 
{Bacteria : Monitor JBacteriaLCvel —* Display Status Jl) 

{02status : MonitorJ02Level —♦ ControLWaterSlowS), 

{NH3Status : MonitorS!HZSevel -* ControLWaterSlowJl), 

{H20Status : Monitor JR20Sevel —► ControLWaterSlowS), 

{02 : Monitor j02Sevel —* DisplayStatusS), 

{NH3 : Monitor JNH3Sevel —> Display Status J2), 

{H20 : Monitor J120Sevel —* Display Status J2), 

{Activatesnlet : ControLWaterSlowS —* Adjust Jnlet), 
{Activate.Drain : ControLWaterSlowS —* Adjust Strain), 
{InletSetting : AdjustSnlet —* DisplayStatus-2), 

{DrainSetting : AdjustSrain —* Display Status J2), 

{Feeding : Controls eeder —» Display Status J2)] 

ERa = {{02Status : Monitor.02Sevel —* ControLWaterSlow), 

{NH3Status : MonitorSH3Sevel —» ControLWaterSlow), 
{H20Status : MonitorS20Sevel -* ControLWaterSlow), 

{02 : Monitor.02Sevel -♦ Display Status), 

{NH3 : MonitorsH3Sevel —» DisplayStatus), 

{H20 : MonitorS20Sevel —* DisplayStatus), 

{Activatesnlet : ControLWaterSlow —» AdjustSnlet), 
{Activate.Drain : ControLWaterSlow —» AdjustSrain), 
{InletSetting : AdjustSnlet DisplayStatus), 

{DrainSetting : AdjustSrain —* DisplayStatus), 

{Feeding : ControlSeeder —» DisplayStatus)} 

CAa = {max.exec.time{MonitorSacteria.Level,lOOnris), 
max.exec.time{DisplayStatusS, 100ms), 
max-exec.time{ControLWaterSlowJl,2QQms), 
period{ControLWaterSlowJ2, 2000ms)} 

CRa = {Tnax.exec.tiTne{Di3playStatus,lQ0ms), 

Tnax.exec.time{ControLWaterSlow,20Qms), 
per iod{ControLWater Slow, 2000ms)} 


Figure 3.14: Example of change AA applied to Fishies 
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Figure 3.15: Fishiest 


AaFishies 

VAb 

VRb 

EAb 

ERb 

CAb 

CRb 


{VRb, VAb, EAb, ERb, CAb, CRb} 

{} 

{GetJ'etdingJTime} 

{} 

{{Fetd^Schedule : EXT —» GetJ'eedingJ'ime), 
{Feed.Schedule : Get-FeedingJTime —* EXT)} 


Figure 3.16: Example of change AB applied to Fishies 
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Figure 3.17: Fishiest 


FishiesM = Fishiesx[Fishies]FishiesB = 

(Fishiesy^ - Fishies) \J{FishiesAr\FishiesB) \J{FishiesB - Fishies) 
= VFi.HU.AVFi.kic.]VFi.hic.s = 

EFi,hic3u = EFi3hicsA^Fi3hic$]EFi,hiciB ~ 

{EFi3kU3. - EFi.HiMEFi3Kir3.nEFi3ki33s)U{EFi3HU3B - EFi3Hir3) 
CFi3KU3^ = CFi3HU3ACFi3Mc3]CF,3Hi3.B = 

{CFi3hic3ji - C'F<.hi«)U(C'F.-.W«., nC'Fi,W«B)U(CFt.Ai«B - 


Figure 3.18: Performing the Change-Merge Operation 









There are a number of possible conflicts that can arise during the merging operation. 
Conflicts arise when different changes applied to the prototype affect the same portion of 
the prototype in different ways. Some examples of conflicts are as follows; 

1. One change adds an output edge to a vertex A, while another change removes 
vertex A from the prototype. In this case, automatic resolution of the conflict is not yet 
possible, so the system would have to announce that a conflict has occurred and give the 
designer the opportunity to resolve it. In the case of such a conflict the construction produces 
a graph that is not well formed, in the sense that it has edges whose endpoints do not belong 
to the vertex set of the graph and are distinct from the artificial node EXT that serves cis 
an endpoint for external flows. 

2. The two changes assign different timing constraint veilues to the same operator, 
i.e., (max-exec.time, F,50ms) and (max-exec.tiTne,F,iOTns). In this case, the conflict can 
be handled automatically, since any operator that executes in under 40ms must also execute 
in under 50ms. In situations where different maximum execution times have been assigned, 
the minimum value can always be chosen. This is also true of two different values for latency, 
maximum response time, and finish within timing constraints. The minimum calling period 
timing constraint would have to be merged using the maximum of the different values. 
Different period values for the same operator in different changes result in a conflict that 
would have to be resolved by the designer. Different control constraints for the same part of 
the prototype in different changes can also result in a conflict. Some of these conflicts can 
be resolved automatically. 

2. Analysis 

The approximate method described above provides a method of change-merging 
PSDL implementations that is closer to the semantically correct version than the first at¬ 
tempt, but impossible to prove correct. The next two chapters detail a slicing method for 
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change-merging which is easily proven correct. Chapter IV details a semantic model of PSDL, 
a method of slicing PSDL programs, and a change-merge model which utilizes these slices to 
create a merged version which preserves the significant changes in each of the two modified 
versions. Chapter V details the algorithm developed to implement this slicing method for 
change-merging. This new slicing method heis been implemented and integrated into the 
CAPS development system. 


G. CONDITIONAL MERGING OF WHILE-PROGRAMS 

One of the main weaknesses of traditional approaches to data flow analysis and slicing is 
insensitivity to the conditions under which data flows actually take effect. This problem has 
prevented conflict-free merging of software changes that affect the same output variable, even 
in Ccises where the changes affect disjoint portions of the input space. One way to improve on 
this is to augment the dependency graphs with flow guards, so that disjoint partial flows can 
be distinguished, and successfully merged. A software merge technique based on conditional 
slices captures a finer-grain picture of the threads in a program than merging beised on 
unconditional slices, and hence can produce more aiccurate program merges. 

1. Conditional Flow Dependencies 

There is a flow dependency between two statements in a while-program if a value 
assigned by the first statement can be re«id by the second statement. Determining flow 
dependencies exactly is undecidable in the general case [Ref. 13]. Conventional data flow 
analysis calculates a weak approximation to the exact flow dependencies by assuming that 
all paths in the control flow graph of a program are feasible. This method ignores the 
possibility of infeasible paths and non-terminating loops because of its assumption that all 
control predicates are satisfiable along all possible paths through the control flow graph. 


45 






Conventional flow analysis is guaranteed to find all flow dependencies, but it may report 
some dependencies that are not really there. 

In [Ref. 13], Berzins introduces conditional flow dependencies to provide more ac¬ 
curate computable approximations to excict data flow dependencies. A conditional flow 
dependency is a conventional flow dependency augmented with a predicate describing the 
conditions imder which the data flow can take place. The predicates cissociated with the 
data flows enable us to recognize disjoint flows and hence provide a more discriminating 
model of the data flow dependencies in a program. 

a. Flow Guards 

The predicates associated with each conditional flow dependency are called 
flow guards. The exact flow guard associated with a flow dependency carried by a variable 
V from a program statement si to another program statement s2 is true in a program state 
S if and only if all of the following conditions hold: 

1. Statement si assigns a value to variable v when executed in state S. 

2. Program execution will subsequently reach the statement s2. 

3. Statement s2 will read the value assigned by statement si to variable v. 

An approximate flow guard must be true whenever the exact flow guard is 
true, and can be true in some Ccises where the exact flow guard is false. The set of all 
approximate flow guards forms a lattice with respect to the ordering defined by the logical 
implication relation. The weakest approximate flow guard is true for all states, and the 
strongest approximate flow guard is the exact flow guard. Conventional data flow analysis 
is equivalent to using the weakest approximate flow guards. 

Checking whether exact flow guards are disjoint is undecidable in the general 
case, as demonstrated by the program shown in Figure 3.20. Statements are identified by the 
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line numbers shown on the left margin. The flow guard for the flow of x from statement 1 to 
statement 4 is disjoint from the flow guard for the flow of y from statement 2 to statement 4 
if and only if the program fragment P shown on line 3 terminates, which is an undecidable 
question. Since program merging algorithms based on conditional flow dependencies need to 
check whether flow guards are disjoint, we seek representations for which disjointness checks 
are decidable. 


1 x;=l 

2 y:=2 

3 P 

4 z:=:x + y 


Figure 3.20: Undecidability of Disjointness for Guard Conditions 

We can get approximate flow guards with decidable disjointness relations by 
using a logic with restricted expressive power to represent the flow guards. One way to do 
this is to use propositional guard predicates. 

Propositional guMd predicates axe constructed from the Boolean constants true 
and false. Boolean condition variables associated with the control predicates, the Boolean 
connectives |, and ~, and the modal operators of the form {P), where P is the condition 
variable associated with the control predicate of a while loop in the program. 

Propositional guard predicates are interpreted as follows. Condition variables 
represent the value produced by the most recent evaluation of the associated control predi¬ 
cate. The connectives &, |, and ~ represent the “and”, “or” and “not” operators of standard 
propositional logic. 
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P = (F*) “begin” (F*) “is” S “end” (V*) 
S = V:=E 


I ‘S'; 5 

I “if” E “then” S “else” S “fi” 
I “while” E “do” S “od” 


Figure 3.21: While Program Grammar 
b. Conditional Dependency Graphs 

Conditional flow dependencies are represented by a conditional program de¬ 
pendency graph. A conditional program dependency graph consists of a set of vertices and 
a set of edges. The set of vertices contains a vertex for each assignment statement, an 
initial^tate vertex, and a final vertex for each output variable. The set of edges repre¬ 
sent conditional flow dependencies and control dependencies. Control dependency edges are 
needed to provide a flow path between two sequential parts of a program which do not share 
any variables. Control dependency edges are identical to flow dependency edges that do not 
CMry a variable. 

We illustrate the construction of a conditional flow graph in terms of a simple 
imperative programming language that provides assignments to scalar variables, sequencing, 
conditionals, and while loops. This language of while-programs does not have any explicit 
input or output statements, and is defined by the grammar shown in Figure 3.21. 

The nonterminals P, S, E, and V represent while-programs, statements, ex¬ 
pressions, and variables, respectively. The Kleene star (*) denotes zero or more instances of 
the preceding symbol. 

The input variables of a while-program are listed before the “begin”, and the 
output vairiables are listed after the “end”. All other program variables are listed between 
the keywords “begin” and “is”. The meaning of a program is characterized by the final values 
of its output variables. The meaning of a program statement is characterized by its effect 
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on the program state. The program state consists of the values bound to all of the program 
variables. The meaning of an expression is characterized by the value of the expression in 
the current program state. The evaluation of an expression cannot affect the program state. 

An attribute grammar is provided in [Ref. 13] for constructing the conditional 
flow graph for a while-program. The nodes of the flow graph correspond to the cissignment 
statements in the program, along with an extra initial vertex and a final vertex for each 
output variable. Each node is associated with an execution guard. The execution guard is a 
predicate that represents the set of program states in which the statement can be executed. 
Each edge of the flow graph is associated with a variable name and a flow guard. The 
variable name identifies the data carried by the edge. The flow guard is a predicate that 
represents the set of program states in which the value of the variable flows along the edge. 
The flow guard is the conjunction of the conditions that the source node is executed, that 
the destination node is executed, and that all loops on the control path from the source 
node to the destination node terminate. Since each node can define the value of at most one 
variable, there can be at most one edge between any pair of nodes in the flow graph. An 
example of a Conditional Flow Graph is shown in Figure 3.22. 
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2. Conditional Slices 


A slice of a program isolates that portion of the code which affects the program 
behavior with respect to some program statement. A conditional slice must differentiate 
between portions of the code that affect the meaning of that program statement, but under 
different conditions. We define a conditional slice of a while-program, with respect to a 
program statement and a flow guard, on the program’s conditional dependence graph, G. 

For program statement, 5 and flow guard, P, the slice of G with respect to 5 and 
P, G/{S,P} is a subgraph of G and contains adl vertices u; £ G, such that there is a path 
from Vi to 5 along control dependence edges or flow dependence edges not labeled with the 
flow guard ~ P. The edges in the slice are all of the edges that connect the vertices in the 
slice. An example of a conditional slice is shown in Figure 3.23. 


SliceB„,^^)(Final(y), P) 

begin 

y := 0; 

P ifx>0 
then 

Q while X > 0 do 

y;=y+ x; 

X ;= X -1; 

od 
end if; 
end(y); 



Figure 3.23; Slice Base/{Final(y), F"} 
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A conditional slice of a program is itself a program, as it contains all of the orig¬ 
inal program code which affects the values computed at the final vertex when the input is 
restricted to only those inputs which satisfy the given conditions. 

3. Conditional Program Merging 

Other approaches to merging while-programs use pieces of each of the input versions 
to perform the mergefRef. 28, 48]. One of these program pieces is the part of the two modified 
versions which is the same. This part is known as the preserved part. The remainder of the 
merged program comes from that part of each of the modified versions which is different 
from the base. These parts are called the affected parts of each modification. Construction 
of these program pieces is done using program slicing. 

The preserved part is constructed by comparing slices of each of the modified 
versions with respect to subsets of the program statements. The largest subset of program 
statements that has the same slice in all three versions defines the preserved part. The 
affected part of each of the modified versions is constructed by comparing the slice of the 
modification with respect to each of its vertices against the same slice of the base version. 
If the slices are different in the modification and the base, then that slice is in the affected 
part. 

One of the problems inherent in this method of program merging is its inability to 
distinguish between different changes to the same slice which cannot interfere. Conditional 
slicing alleviates this problem by allowing the different computation paths which can never 
be executed for the same input to be considered separately. 

Using conditional slicing, we calculate the affected part of a modified version by 
comparing slices of the modified version with respect to the program statements and the set 
of eJI possible truth values of the conditional guard predicates at that statement. In this 
way, two different paths to the same statement which cannot be taken on a single input are 
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not contained in the same slice, thus changes to one path do not necessarily affect the slice 
containing the other path. 

The merged program is then constructed in the same way as the unconditional 
method, by taking the graph union of the preserved part and the affected parts of both 
modifications. 

Consider the example outlined in Figures 3.24 through 3.29. In this example, the 
base version is the same as that shown in Figure 3.22 and contains a conditional expression 
that partitions the input space into positive and negative integers. If the input value of x 
is negative, then one set of statements is executed and if it is positive, then another set of 
statements is executed. In Figure 3.24, you see a change made to the then branch of the 
conditional expression. In Figure 3.25, you see a change to the else branch of the conditional. 
Since both of these branches affect the same output variable, y, the traditional approach to 
merging would report a conflict and the merge would fail. This should not be the case, 
however, since these two changes can never interfere. 
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Figure 3.29; Merged Version 





IV. SEMANTIC MODEL 


In this chapter we describe our model for the behavior of prototypes, present our slicing 
method for change-merging prototypes, and present an invariance theorem that guarantees 
our method is correct. 

A. PROTOTYPING SYSTEM DESCRIPTION LANGUAGE 

The Prototyping System Description Language (PSDL) is an enhanced data flow lan¬ 
guage that can be used to specify and implement prototypes of real-time embedded software. 
PSDL programs are inherently non-deterministic and can be executed in parallel [Ref. 32]. 
This section describes a semantic execution model for PSDL programs. 

1. Overview of PSDL Semantics 

Our change-merging method is based on the behavior of the input programs and not 
on their syntax. In this section we define a behavior model for PSDL that we can use to prove 
our invariance theorem. The semantics of PSDL have been modeled using algebraic high-level 
Petri nets [Ref. 32]. We chose a different model which is more applicable to our problem. We 
chose to model the behavior of a prototype by observing the data flow history over its data 
strecims. A prototype’s behavior is represented by sets of possible histories over the streams 
we call trace.tuples. These trace.tuples are composed of sequences of data_tuples called 
traces. Each trace-tuple contains precisely one trace per stream. Since PSDL prototypes are 
non-deterministic, one trace.tuple does not necessarily reflect the set of possible histories 
associated with a prototype, thus we must consider the behavior of a prototype to be the 
set of all possible trace-tuples over its data streams. Since PSDL prototypes are intended 
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to prototype embedded real-time systems, which may never be turned off, this behavior is 
likely to be of infinite length. We use trace.tuples tis the base unit for our inductive proof of 
the invariance theorem in Section B.2 of this chapter. The following subsections describe the 
model starting with traces and building up to the behavior of a prototype, and the possibility 
functions we use to construct the behaviors. 

2. Traces 

The history of a PSDL computation can be described by the histories of all the 
data streams, called traces. A tract on a data stream x, denoted is the sequence of all 
data tuples on the stream. Each data tuple contains a data element xj, the name oj of the 
operator responsible for writing xj to the stream, the time tw\ that x; was written to the 
stream, cind the time trj at which oj read its input streams to steirt the computation that 
produced Xj. A data tuple represents the cissertion that the value Xj was produced by an 
execution of o\ that started at time tri and finished at time twi. 

Example 1 Trace on a stream x 

Tx = [[xo,Oo,tro,<t«o],[a;i,Oi,tri,tu)i],...,[xi,oi,<ri,tw;i],...] 

Since PSDL was designed for writing prototypes of real-time embedded software 
systems that may never be turned off once started, traces can be finite or countably infinite. 
The initial data tuple on a data stream is [xo —» ±,Oo —> -L,<w;o —♦ 0,fro —* 0], where 
J. represents an undefined value, unless the stream is decided as a state variable with an 
initial value, in which case the initial data tuple would be [xq —» v, Oq —► DECL_OP, two —* 
0,tro —* 0]. DECL_OP is the operator in which the state declaration appears, and v is the 
initial value assigned in that declaration. For example, if the state stream is declared in an 
operator p by the declaration statement STATE x INITIALLY 3, then the initial data 
tuple on the stream would be [3,p, 0,0]. Since every trace contains an initial data tuple, 
we see that all traces are non-empty and that the minimum length of a trace is one. In a 
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data flow stream, when a data element is removed from the stream and there is not another 
element on the stream, the value and the operator name elements are replaced by ±. 

The write times tw\ for a given stream form a monotonically increasing sequence 
of numbers that represent the amount of time elapsed between when the prototype began 
execution and when the value was available on the stream. The read times tr\ for a given 
streain form a monotonically increasing sequence of numbers; the ith element in the sequence 
represents the amount of time elapsed between when the prototype began execution and when 
the operator oj read its input streams at the start of the computation responsible for x\. 

If an operator fails to terminate on any firing, then the trace on any of its output 
streams contains only the values which were written to the stream before the firing in which 
the operator failed to terminate. If the failure to terminate occurs during the first firing and 
no other operator can write to the stream, the trace contains only the data tuple representing 
the initial value. 

A trace, can also be represented by a stream function from a write time to a 
triple containing the value, the id of the operator which wrote the value and the read time: 
4' : TIME —> TYPE{x) x OPJD x TIME, where TYPE{x) denotes the set of all 
possible values that can be written to the stream x, OPjD is the set of all possible operators 
that can write to the stream, and TIME is a non-negative real number. We chose time to 
be a continuous value since prototypes can be executed in pcirallel, and we cannot guarantee 
that different processors will execute a precisely the same speeds. 

Example 2 Stream Function Representation for a Trace 

A trace for a stream x is: 

T, = [[J., X, 0,0], [x„ o, 2,3], [X2,p, 6, 7]] 
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The stream function representation for this trace would be: 

( [0,3) — [±,±,0] 

[3,7) ^ [x„o,2] 

i [7,oo) — [x 2 ,p, 6] 

In order to use these different representations interchangeably, we need to show 
that they are equivalent. Consider the function, $, shown in Figure 4.1. $ is a bijection 
that maps a sequence of data tuples into a step function, 4', which is continuous only from 
the right. 

«'(<) = Hm ,Vi 

Limits from the left are not preserved at the boundaries between the data tuples, however. 

Theorem 2 ^ is well-defined and a bijection when restricted to right continuous step func¬ 
tions with countable range sets. 

Proof : See Appendix C. 

<I>(T;j) = ^< 3;, where ^'^(t) = [Xn,On,<rn] 

where [xn)On,<w^n)<'’ii] € t„ n € H & twa < f & (n = length(Ti) or > <) 

= Tx where [xi,o, ftni.trj] € t, iff 

( <I'3;(tu;i) = [xi, o, fn] &: twi = mint(^'*(<) = [xi, o, tri]) ) 


Figure 4.1: $ : Traces —* FunctionRepresentations 

The meaning of an operator is characterized by a relation between the traces on 
the input streams and the traces on the output streams. If a data stream receives input from 
more than one producer, then we must have a method for merging multiple traces into one 
to determine the behavior of the entire system. The merge function, defined in Appendix 
A, Section 3, provides this method for two traces, A «ind B. It can e2isily be generalized to 
any finite number of traces. 
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A stream behavior {or a stream i, 0^, is the set of all possible traces for x. Since a 
PSDL computation can be non-deterministic, the history of a computation is represented by 
the set of all possible traces for a given PSDL stream. Since the complete stream behavior 
for a data stream in a PSDL prototype may not be visible from outside the prototype, it 
is necessary for us to consider both visible and generated stream behaviors for a stream. A 
visible stream behavior for a stream z is a set of traces written to x by an external producer. 
Each trace in the visible stream behavior of z is a subsequence of some trace in the complete 
stream behavior for z. The part of the stream behavior which is not produced externally, 
we call the generated stream behavior. The traces in the generated stream behavior for x 
axe also subsequences of traces in the complete stream behavior for z. For example, consider 
either of the prototypes in Figure 4.2. Each trace in the stream behavior of z, is a sequence 
which contains as subsequences the traces on the hidden and visible parts of z. Thus the 
visible behavior and the generated behavior are both projections of the complete stream 
behavior. 


A truncated trace for a stream z, t* | A;, is a finite prefix of for which length(rx \ 
k = min{length{rx), k) A truncated stream behavior for a stream x, 0x \ k is the set of all 
possible truncated traces, r* | k. 

3. Trace Tuples and Prototype Behaviors 

A trace tuple is a tuple containing a trace for each stream in a prototype. A trace 
tuple can be projected downward to any subset of the streams in a prototype, say X, by 
including in the projected trace tuple only those traces on the streams in X. A trace tuple, 
r, projected downward to a subset X of the streams of the prototype is represented as Tx- 





Figure 4.2: Example of prototypes with generated stream behaviors. 
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An example of a trace tuple over the set of data streams in a prototype £(P) is 
Xi e E{P). A visible trace tuple is a tuple of visible traces for each stream 
in the prototype. A truncated trace tuple is a trace tuple containing only truncated traces: 

|fc)> 

A trace tuple can also be viewed as a vector-valued stream function by extending 
the function 4> to trace tuples according to the rule: 

'9{t) is a vector containing one data tuple from each trace in the trace tuple, the value 
present on each stream at time t. Using 4>, we can also view a trace tuple as a sequence of 
vectors, where each vector contains the data tuple present on each stream at a write time t 
for one of the streams in the tuple. 

Example 3 Example of a Trace Tuple on two streams. 

For a set of streams X = {x,y} with = [[±, ±,0,0], [xi,o,2,3], [x2,p, 6,7]] and 
Ty = [[±, ±,0,0], [yi,o,3,5],[y2,o,7,9]], the resulting trace tuple is: 

([[±, ±, 0,0], [xi, o, 2,3], [X2,p, 6,7]], [[±, ±, 0,0], [y^, o, 3,5], [y2, o, 7,9]]) 

and the corresponding function representation is: 

[0,3) ([±,±,0],[±,±,0]) 

[3,5) — ([xi,o,2],[±,±,0]) 

[5,7) — {[x:,o,2],[y„o,3]) 

[7,9) —► ([x2,p,6],[yi,o,3]) 

[9,oo) —» {k,P,6],[y2,o,7]) 

Since PSDL is non-deterministic, there may be many possible trace tuples for a 
prototype P. We call the set of all possible trace tuples for the data streams in P, the 
prototype behavior of P, and we represent it as B. 
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A prototype behavior can also be projected downward to any subset of the streams 
in a prototype, say X, by including in the projected data flow history only the possible 
projected trace tuples over X. A projected data flow history over a set of streams X is 
represented as Bjf. An input prototype behavior for a prototype P is the set of all possible 
visible trace tuples over the streams in P. 

Example 4 Example of a projected prototype behavior on a set containing two streams. 

Consider the following set X = {x,y}, where the stream behavior for i is a single 
trace, [[±, ±, 0, 0], [xi, o, 2,3], [x2,p, 6,7]] and the stream behavior for y contains two dif¬ 
ferent traces, {[[±, ±, 0,0], [j/i, o,3,5], [t/2) o,7,9]], [[±,±,0,0], [yi,o,4,6), (j/j.o, 6,8)]}. Then 
the resulting prototype behavior, B;r is: 


{([[±, ±, 0,0], [xi, o,2,3], [X2, p, 6,7]], [[±, 1 , 0,0], [3/1,0,3,5], [^2,0,7,9]]>, 


([[1, 0,0], [xi,o,2,3], [X2,p,6,7]], [[±,±, 0,0], [yi, o,4,6], [y2,o, 6,8]])} 


The function representation corresponding to Bx is: 


[0,3) 

—, 

([±,±,0],[±,±,0]) 

[3,5) 

—» 

([xj,o,2],[±,±,0]) 

[5,7) 

—> 

([xi,o,2],[yi,o,3]) 

[7,9) 

—► 

{[a:2,P,6],[yi,o,3]) 

[9,00) 


<[a:2,P,6], [^2,0,7]), 

[0,3) 


([±,±,0],[±,±,0]) 

[3,5) 

—> 

([x„o,2],[±,±,0]) 

[5,6) 

—» 

{[xi,o,2],[yi,o,4]) 

[6,8) 

—» 

{[a:2,P,6],[y„o,4]) 

[8,00) 

—► 

([i2,P,6],[y2,o,6]) } 


A truncated prototype behavior, B | A: is the set of all possible truncated trace tuples, up to 


length h. 


To prove our slice behavior inv^iance theorem, we also need to extend truncated 
trace tuples of length k to length A: 4- 1 by adding one data tuple onto selected traces in 
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the trace tuple. We define an incremental trace tuple to be a vector of sequences of data 
tuples over a set of streams, where the length of each sequence is either zero or one, and the 
write times for all of the data tuples are the same. An incremental trace tuple represents the 
output caused by one firing of a set of zero or more operators writing to different streams of 
the prototype. We need a function © for appending sets of possible incremental trace tuples 
on to the end of a truncated trace tuple. The © function is defined in Appendix A. This 
function takes as operands, a truncated trace tuple over the streams in a prototype and a 
set of possible incremental trace tuples over the streams in the prototype, and it produces 
the set of all possible trace tuples resulting from adding each of the incremental trace tuples 
onto the end of the corresponding sequence in the original trace tuple, for each data stream. 
Figure 4.3 shows a summary of the constructs defined in the semantic model of PSDL. 


time 

dataJuple{t : type) 
trace 

stream.hehavior 

trace-tuple 

incremental JraceJuple 
prototype-behavior 


{z e » I X > 0} 

tuple{x :t,o: opJd,tr,tw : time] 

sequence{data-tuple) 

set{trace) 

tuple{streami : trace} 

vector{t : trace) :: length{t) < 1 

set{traceJuple) 


Figure 4.3: Summary of Model Constructs 


4. Possibility Functions 

Each operator in a PSDL prototype has an input history and an output history. 
The input history of an operator o is defined as the prototype’s behavior projected over the 
input streams of o, 6/(0), and the output history of o is the set of all possible trace tuples 
written by o to its output streams. 

In a PSDL prototype, when an operator fires, it reads one data value from each of 
its input streeuns and writes at most one output value to each of its output streams. The data 
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values written and the streams they are written to are determined by the semantic meaning 
of the PSDL operator and the associated control constraints. Since PSDL operators are 
non-deterministic, their meanings are possibility functions. For every possible input, there 
is a set of possible outputs. 

To define the possibility function for an operator o, we look at a trace tuple pro¬ 
jection of the behavior a G B/(o) as a sequence of input vectors to o. For every finite prefix 
of (T applied to o, the result is a set of possible incremental trace tuples over the output 
streams of o. This is the possibility function for o, To : —» Bo(o). To takes as input 

a projected trace tuple over the input streams of o and a read time, and produces a set of 
possible behavior projections over the output streams of o. The read time is the time at 
which the last read operation was performed by o on its input streams, and defines which 
values were read by o to perform this computation. 

Example 5 Possibility function for an operator p which implements the function; 

Vk = 

= {({3}, 9), ({3, -4}, 16), ({3, -4,9}, 81),..., ({3, -4,9, ^**),...} 

Example 6 Possibility function for an operator q which implements the state machine: 

y* = S 

= {({3},3), ({3, -4}, -1), ({3, -4,9},8),^{3, -4,9,...,x.}, (gx.) + x*j ,...} 


In example 5 you will notice that the y value of each pair is dependent only on the 
most current value written to the input stream x. In example 6 the y value of each pair is 
dependent not only on the most current value written to the input stream x, but also on the 
previous value of y. 
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The effects of all PSDL control constraints can be expressed as transformations 
on the possibility function of a bare primitive operator. The effect of each type of control 
constraint on a possibility function is defined explicitly in Appendix B. In the rest of this 
chapter, we assume that the possibility function for each operator includes the effects of any 
associated control constraints. 

To analyze the effects of various approaches to change merging, we cissume that 
the possibility function for a network of PSDL operators can be derived from the possibility 
functions for the individual operators in the network. This can be done as follows. 

We consider a prototype P to be a network of operators connected by the data 
streams of P, with behavior B. B is the behavior of the entire prototype. Each operator 
contributes to this behavior by reading from its input streams and writing to its output 
streams. The values written are determined by the possibility function of the operator. We 
can derive the possibility function for the prototype P from the possibility functions of the 
individual operators using the following construction: 

^p=u[ U f©f U (u 

T€B L«^(V(P)) \oes \,(T.o)<tT \tr<t / / / J 

This construction produces a set of incrementaLtrace_tuples over all of the streams 
in P. The possibility function for each individual operator is at the heart of this con- 
'struction. It produces a set of incrementaLtrace-tuples over its output streams. This incre- 
mentaLtrace.tuple is extended to cover all of the streams in the prototype by the function 
fill. The function A is then used to isolate each incrementaLtrace_tuple attributable to a 
particular read time tr and these are combined over all possible read times up to the current 
time t. These incrementaLtr«ice-tuples are then combined using the function p to pick out 
the latest possible write time or read time depending on whether the operator contains a 
feedback loop. Each of these sets of incrementaLtrace.tuples for individual operators are 
then combined with sets produced by other operators in the subset S using the function ©. 
This is done for every possible subset S in the powerset of the vertices of P. Finally, these 
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sets of incrementaLtrace.tuples are combined for every possible trace.tuple in the behavior 
BoiP. 


To construct the truncated behavior of P of size k, we have to not only produce 
the set of incrementaLtrace_tuples, we have to append them to the set of truncated trace 
tuples of size k — 1. That can be done as follows; 

u [ u u fu 

reBK*-!) Lse7’(v(P)) L Ves \p(T.o)<tr \tr<t '/Jll 

This construction is identical to the previous construction up to the point where the combina¬ 
tion over subsets occurs. At this point, we must append the set of incrementaLtrace-tuples 
produced by the 0 function for each subset of the operators to the trace.tuple T in the 
truncated behavior B | {k — 1). This guarantees us that we have considered every possible 
combination of operators firing at precisely the same time. The result of this construction 
is then a set of possible trace tuples truncated at length k. This construction assumes that 
the truncated B of size A;— 1 is known. Precise definitions for the functions ©, A, p and fill 
can be found in Appendix A. 

In our work, we assume that execution of the prototype is “fair”, in the sense 
that, any operator which terminates in isolation will terminate when executed as part of 
a prototype. Failure of m operator to terminate is represented by a possibility function 
that gives the same set of possible output sequences for all possible extensions of an input 
sequence that fails to terminate. 

B. SLICING OF PSDL PROTOTYPES 

As we saw in Chapter III, Section C.2, a portion of a program’s behavior can be 
captured by a slice of the program with respect to a single point in the program. We 
have developed a similar method that is also valid for isolating a portion of the behavior of 
a prototype. This section describes our method for taking slices of PSDL prototypes. One 
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of the differences between slicing for PSDL prototypes and slicing for while programs is that 
PSDL programs are inherently concurrent and non-deterministic. While programs represent 
individual deterministic sequential processes. This represents a major contribution of this 
work. 

1. Prototype Dependence Graphs 

Since PSDL implementations are graphs, we do not need a deep transformation to 
translate our prototypes into graphs as is the case for while programs. The only information 
we need to add to the current PSDL implementation graph are dependencies resulting from 
timer interactions, and an external vertex. The external vertex is added to allow slices of 
prototypes with vertices that have no outputs to include those vertices. The following defines 
our Prototype Dependence Graph (PDG); 

Definition 4 PSDL Prototype Dependence Graph: 

A Prototype Dependence Graph fPDGj /or a prototype P is a fully expanded * 
PSDL implementation graph Gp. In the PDG, G/> = (V, E,C), the set of vertices has been 
augmented with an external vertex, EXT, and the set of edges, E, has been augmented with 
a timer dependency edge from o-, to oj, for each pair of vertices oj, oj € V such that the 
control constraints of oj contain timer operations which affect the state of a timer read by 
the control constraints of oj . 


Values on a timer dependency edge can be modeled precisely in the same way as 
values on a data stream. A data_tuple on a timer dependency edge can be viewed as a tuple 
containing the following for each of the tuple components: 

v: A pair (c,t) containing the operation c e (Start, Stop, Reset) that last changed 
the state of the timer and the value t of the timer at the time of the state change. 
op: The id of the operator which last changed the state of the timer. 
tw: The time of the last state change. 

tr: The time that op read its input streams before the firing 
that produced the state change in u. 

* A fully expanded PSDL implementation graph is one in which every vertex represents an atomic operator. 
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For example, consider the data_tuple [(start, 25),p, 36,34] on the timer stream 
Tirntrl. In this example, the v element of the data tuple is the pair (start,25), the op 
element is p, the write_time is 36, and the read_time is 34. This means that the operator p 
read its streams at time 34, started the timer Timer], at time 36, and the current value of 
the timer when the state change was executed was 25. This view of timer dependency edges 
allows us to treat them the same as any other edge in the graph. 

Top level prototypes do not contain inputs or outputs, so there will always be 
vertices which do not write to a stream. Since we construct our slices from sets of streams 
and not from vertices, as in slicing of while programs, these vertices could never be included 
in a slice. The external vertex is added to provide a way to capture these vertices during 
slicing. During construction of the PDG for a prototype, an artificial edge is added to the 
graph from any vertex which does not write to an output stream to the external vertex 
EXT. These edges are then considered in the construction of the slices of the prototype, 
thus allowing those terminal vertices an opportunity to be included. Only one external 
vertex is needed for this graph, because each artificial edge added is given a unique name, 
and considered separately in the construction of the slice. 

2. Slicing Theorem 

A slice of a PSDL prototype is defined in terms of the prototype’s dependence 
graph. It contains the portion of the prototype which affects the history of a set of streams. 
This is useful in isolating changes made to a base version of a prototype in a modification. 
If the slices of two versions with respect to the same set of streams are different, then there 
are significant changes that have been made to one version and not the other. 

Informally, a slice is an upstream closure of a set of edges in the graph that includes 
all the source nodes for the edges in the slice. A formal definition of a slice follows: 
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Definition 5 Slice of a PSDL Prototype: 

A slice SpiX) of a PSDL prototype P with respect to a set of data streams X is 
the subgraph {V,E,C) of the PDG Gp where: 

(1) V is the smallest set that contains all vertices Oi € Gp that satisfy at least one 
of the following conditions: 

a) Oi writes to one of the data streams in X. 

b) O’, precedes Oj in Gp, and oj G V. 

(2) E is the smallest set that contains all of the edges Xk € Gp which satisfy at 
least one of the following conditions: 

a) Xk € 

b) is directed to some oi € V. 

(S) C is the smallest set that contains all of the timing and control constraints 
associated with each operator in V and each data stream in E. 

Example 7 Figure 4-4 shows a prototype for a fish farm control system called Fishies. 
Figures 4-5, 4-6 and ^.7 display different slices o/Fishies. 


Theorem 3 Slicing Theorem for PSDL Prototypes: 

Let Sp{X) be the slice of a prototype P with respect to a set of streams X. Then 
Sp{X) and P have the same behavior on any subset of the streams in Sp{X). 

The proof of this theorem is contained in Appendix C, Section 2. The significance 
of this theorem is that a slice captures a fragment of the semantic behavior of a prototype, 
and the behavior captured by that slice remains the same even if that slice is made a part of 
a different prototype, provided that it is also a slice with respect to that new prototype. This 
property is the bcisis for constructing a change merging operation that can provide semantic 
guarantees of correctness. 
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C. A SLICING METHOD FOR CHANGE-MERGING PSDL 
PROTOTYPES 

Our change-merging method for PSDL prototypes, illustrated in Figures 4.12 through 
4.15 on the prototype versions originally introduced in Chapter III and shown again in 
Figures 4.4, 4.8 and 4.9 uses prototype slicing to determine automatically which parts of the 
prototype have been affected by a change and which parts have been preserved. 



If the slice of a changed version of a prototype with respect to a stream present in 
both the base version and the modified version is different than the same slice of the base 
version, then the behavior on that slice is likely to be different. Therefore that change is 
significant, and must be preserved in the merged version. For example, consider the slice 
of Fishiesi_i with respect to the stream AclivateJDrain, illustrated in Figure 4.10, and the 
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Figure 4.9: Fishies2.2 
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same slice of Fishiesi_ 2 , illustrated in Figure 4.11. It is easy to see a portion of the effect of 
the change which produced Fishiesi,^ from Fishiesi,i. If we were to take the same slice of 
Fishies2.2, we would discover that it is identical to the slice of the base version of Fishies. 
This illustrates that this part of the Fishies prototype is not affected by the change which 
produced Fishies2.2- Since this change is significant, it must be reflected in the merged 
version. 



Figure 4.10: SFi 3 hicsi.i{-Activate-Drain) 

Slices are important because they capture all of the parts of a program that can affect 
the behavior visible in a set of data streams. If two different programs have the same slice for 
a set of streams, they cJso have the same behavior over that set of streams. The preserved 
part of a prototype is then the largest set of streams that have the same single stream slice 
in all three versions, «ind the affected streams of each modification are those that have a 
different single stream slice in the modified version than in the base version. Performing 
a change-merge using Fishiesi,i as the base version, and Fishiesi_2 and Fishies2.2 as the 
modified versions, we get the preserved part as shown in Figure 4.12 and affected parts as 
shown in Figures 4.13 and 4.14. 
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In constructing the preserved part, we consider each stream individually, taking the 
slice of each version with respect to that stream. If the slices are the same, then that slice 
is added to the preserved part. After all streams have been checked, the preserved part is 
complete. 

The affected parts are constructed by comparing the slices of each stream in the modified 
version against the same slice of the base version. The stream is included in the affected 
part if the slices are different. 

The merged version is formed by taking the union of the preserved part of all three 
versions and the affected parts of the two modified versions. If the slice of the merged version 
with respect to the streams affected by each modification is the same as the corresponding 
slice of the modified version, then semantic correctness of the merged version with respect 
to the modifications is established. The result of change-merging Fishiesi.i, Fishiesi ,2 and 
Fi3hies2.2 is shown in Figure 4.15. 

Our slicing method has the advantage of a clear semantic criterion for correctness, and 
the disadvantage of reporting conflicts whenever two changes can affect the same stream, 
regardless of whether there exists a computation history in which the two changes actually 
interact or conflict with each other. 


78 







V. CHANGE-MERGE ALGORITHM 


From the change-merging models for both the specification, shown in Chapter III, and 
the implementation, shown in Chapter IV, we developed a change-merging algorithm. This 
change-merging algorithm takes advantage of the fact that the specification and implemen¬ 
tation can be change-merged separately to create a correctly change-merged program. This 
chapter outlines the change-merging algorithm in detail and provides a piece by piece analy¬ 
sis of the algorithm for correctness, complexity and coverage. This algorithm was written to 
accept a base version and two modifications as input. It is Ccisily extended to change-merge 
the result of n modifications to a base version by applying the algorithm iteratively using 
the result of the most recent application as one input and the next modification as the other. 
The result of a successful iterative application on n versions is a merged version containing 
the significant behaviors of each of the inputs. 

The algorithm changejnerge accepts three expanded versions of a PSDL program as 
input. It then extracts all of the PSDL components from each version of the program. 
The atomic components are held in storage to be included in the change-merged version 
of the program if needed, and the composite component of each program is divided into a 
specification part and an implementation part. 

Each of these parts are change-merged separately and the results are recombined to cre¬ 
ate the change-merged composite component. From the implementation part of the change- 
merged composite component, the algorithm can deduce which of the atomic components 
need to be included in the change-merged program. The change-merged program is then re¬ 
turned. If a conflict is detected during the change-merging process, the CONFLICT waxiahle 
is set to true, and a flag is placed into the change-merged program at the location of the 
conflict to aid the designer in locating and resolving it. Figure 5.1 shows the change-merge 
algorithm. 



Algorithm change_merge(5A5£, : in psdLprogram; CONFLICT : out boolean) 
return psdLprogram 

1. Extract the psdl.components from each of the input psdLprograms. 

2. Change-merge the specification parts for the three input composite components. 

a. Change-merge the state declarations. 

b. Change-merge the exception declarations. 

c. Change-merge the mcocimum execution times. 

d. Change-merge the formal and informal descriptions. 

3. Change-merge the implementation pMts for the three input composite components. 

a. Create the prototype dependency graphs for each version. 

b. Create the affected parts of each modified version. 

c. Create the preserved pcirt of the base in all three versions. 

d. Change-merge the graphs. 

e. Change-merge the stream declarations. 

f. Change-merge the timer declarations. 

g. Change-merge the control constraints. 

(1) Change-merge the trigger constraints. 

(2) Change-merge the execution guard constraints. 

(3) Change-merge the periods. 

(4) Change-merge the finish.withins. 

(5) Change-merge the minimum calling periods. 

(6) Change-merge the maximum response times. 

(7) Ch2inge-merge the output guard constraints. 

(8) Change-merge the exception trigger constraints. 

(9) Change-merge the timer operations. 

4. Create the change-merged program. 

a. Combine the change-merged specification and implementation. 

b. From the resulting implementation, determine which of the atomic components 
from each of the input versions is to be included in the change-merged program. 

5. Return the change-merged program, 
end Change_Merge; 


Figure 5.1: Algorithm changejmerge. 





A. EXTRACTING THE COMPONENTS 


Extracting the components from each of the input PSDL programs is done using a 
map fetch operation. The algorithm loops through each of the input programs and retrieves 
the set of components each one contciins. The atomic components are placed in a holding 
program so they can be retrieved later if needed for the merged program, and the composite 
component is extracted for change-merging. The algorithm fragment used to extract the 
components is shown in Figure 5.2. 


a. For every component in the Base Version loop 

(1) Fetch the component; 

(2) If the component is atomic then bind to holding program for base version; 

(3) else extract the component; end if; end loop; 

b. For every component in the A Version loop 

(1) Fetch the component; 

(2) If the component is atomic then bind to holding program for base version; 

(3) else extract the component; end if; end loop; 

c. For every component in the B Version loop 

(1) Fetch the component; 

(2) If the component is atomic then bind to holding program for base version; 

(3) else extract the component; end if; end loop; 


Figure 5.2: Algorithm Fragment for Extracting the Component. 

The extraction part of the algorithm requires a loop through the components of each 
version to perform the fetch. The correctness of this algorithm fragment can be shown using 
simple induction. Since the operations inside the loop are constant and the loop is executed 
only once for each component of each program, the worst-case complexity of this part of the 
algorithm is 0{n), where n is the number of components in the program. This algorithm 
fragment can be used for all fully expanded PSDL programs, since they contain only one 
composite component. 
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B. CHANGE-MERGING THE SPECIFICATIONS 

Change-merging the specification of the top level component requires five operations. 
The five operations are responsible for change-merging the components of the specification: 
the state declarations, the maximum execution times, the exception sets, and the informal 
and formal descriptions. 

1. Change-Merging the State Declarations 

Change-merging the state declarations is done with the procedure merge^tates. 
Since the state declarations are a set, normal set operations may be used to merge the state 
declarations themselves, but the initial values of the state variables conform to a flat lattice 
structure and any change must be preserved. The algorithm mergeMates is shown in Figure 
5.3. 


To show correctness of merge^tates, we must show that it correctly implements 
the equation {A — Base)\j{AriB)\j{B—Base). Two internal loops construct this equation. 
The first loop captures any state variable declaration which appears in A, but not in BASE; 
the (A — Base) part of the equation, and then captures iiny state variable declaration which 
appears in both of the modified versions; the {A n B) part of the equation. The second 
loop captures any state variable declaration which appears in B, but not in BASE; the 
{B — Base) part. Since both loops add state variable declarations to the same set MERGE, 
the union part of the equation is satisfied. 

The execution of merge^tates requires a membership test and add operation for 
every state declared, and these are both linear time operations with the current linked-list 
implementation of sets. Thus the entire algorithm requires time, where s is the number 

of states declared. This can be improved to C?(slogs) if balanced trees are used for the sets. 
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Algorithm merge^tates{MERGE: in out type.declaration; 

BASE, A, B: in type.declaration; 

MERGEJNIT: in out initjnap; 

AJNIT, BJNIT: in initjnap) 

begin 

for every state variable, s, declared in A 
if s is not in BASE, and s is not in B then 

add s to MERGE-, add initial value to MERGE JNIT-, 
end if; 

if s is in B then 
add to MERGE-, 

if the initial values are the same in AJ NIT and BJNIT then 
add initial value to MERGEJNIT; 
else add conflictjexpression to MERGEJNIT-, 
end if; 
end if; 
end loop; 

for every state variable, s, declared in B 
if s is not in BASE and s is not in A then 

add to MERGE-, add initial value to MERGEJNIT-, 
end if; 
end loop; 

end merge^ates-, 

Figure 5.3: Algorithm mergejitaies. 




2. Change-Merging the Maximum Execution Times 


Change-merging the maximum execution time constraints is done with the function 
merge^met, shown in Figure 5.4. Maximum execution times follow a Brouwerian Algebra 
structure as shown by Proposition 2 in Chapter III, Section D.2, and must be merged ac¬ 
cording to those rules. 


Algorithm me.rgtjmet{BASE, A, B : millisec) return millisec 
AJDIFF^ASE, BJ)IFF^ASE, AJNTJ: millisec; 
begin 

A < B then 
AJNTJ := B; 

else AJNT^ := A; 
end if; 

if BASE < A then 
AJDIFF^ASE := ±; 
else AJDIFF^ASE := A; 
end if; 

if BASE < B then 
BJ)IFF^ASE ;= J.; 
else B-DIFFJASE := B; 
end if; 

if AJ^IFF-BASE < AJNT^ then 

if A-DIFF-BASE < BJDIFF^ASE then 
return A-DIFF-BASE; 
else return B-DIFF.BASE; 
end if; 

else if AJNT.B < B.DIFF.BASE then 
return A-INT-B; 
else return B-DIFF-BASE; 
end if; 
end if; 

end mergejnet; 


Figure 5.4: Algorithm mergejnet. 


The algorithm for change-merging maximum execution times must also satisfy the 
change-merging equation (A — Base) U (A fl B) U (5— Base). It uses a series of conditional 
expressions to c£ilculate the values of A-DIFF-BASE, B-DIFF-BASE, and AJNT-B, 
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which represent the {A — Base), {B — Base) and Ar\B parts of the equation shown above. 
It then combines them according to the rules outlined in Chapter III, Section D.2. "fiiis 
adherence to the mathematical model guarantees the correctness of the algorithm. Since 
this algorithm contains no loops, it requires constant time to execute, so the worst-case time 
complexity of mergejnet is 0(1). 


3. Change-Merging the Exception Declcirations and Keywords 


Change-merging the exception declarations and the keyword sets is done using 
the merge-id.sets function shown in Figure 5.5. This algorithm calculates the equation 
[A — Base) U (-4 n B) U (5 — Base) in precisely the same way as merge^tates calculates 
the merge of the state decimations without the initial values. 


Algorithm merge.id.sets(BASE,A,B : idjset) return id^et 

Calculate A — BASE. 

Calculate B - BASE. 

Calculate A fl -B. 

Return [A - RABf;)U(AnB)U(B - BASE). 
end merge.idjsets\ 


Figure 5.5: Algorithm TnergeJd.sets. 

The correctness and complexity analyses of mergeAdLsets are identical to those of 
merge.staies, so merging id^ets requires worst case 0(x*) time for exception declarations 
and 0{k'^) time for keywords. 

4. Change-Merging the Descriptions 

Change-merging both the informal and the formal descriptions is accomplished 
using the function mergeJer* shown in Figure 5.6. mergeJLext implements a flat lattice 
change-merge, and any change :rom the base version in one 


modification must be identical to 



any change in the other modification or a conflict is produced. This function has a constant 
time complexity. 


Algorithm mergeJext{BASE,A, B : text) return text 
begin 

if BASE = A 
then return B 
else if BASE = B 
then return A 
else if A = 5 
then return A 

else return (“Conflict in text. Must be change-merged manually!”) 
end if; 
end if; 
end if; 

end mergejtext-, 


Figure 5.6: Algorithm mergeJtext. 


5 . Analysis of Specification Change-Merge 

Correctness of the specification change-merge part of the algorithm is guaranteed 
by the correctness of the individual algorithms which make up the specification change- 
merge. The worst-case time complexity of the specification part of the algorithm is obtained 
by adding the complexities of the individual parts as follows: 

0(s") -1- O(x^) -I- O(k^) -I- 0(1) + 0(1) -I- 0(1) = 0(s" + x^ + k^) 

where s is the number of state declarations, x is the mrniber of exception declarations, and 
k is the number of keywords. 

This algorithm is capable of performing change-merge operations on all PSDL 
operator specifications. 
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C. CHANGE-MERGING THE IMPLEMENTATIONS 


Change-merging the implementation parts is also accomplished by change-merging the 
individual parts of the implementation separately. It requires five main operations; change¬ 
merging the graphs, change-merging the stream declarations, change-merging the timer dec¬ 
larations, change-merging the control constraints, and change-merging the informal descrip¬ 
tions. 


1. Change-Merging the Graphs 

To change-merge the PSDL implementation graphs, we must first convert them to 
prototype dependency graphs that accurately reflect all of the timer dependencies between 
operators in the prototype as well as the data dependencies. We do this with the build-PDG 
function shown in Figure 5.7. Next we must construct the preserved and affected parts of 
the three input graphs according to the slicing rules defined in Chapter IV. The algorithms 
for these constructions are contained in Figures 5.9 and 5.8, respectively. Finally, we must 
combine these three parts into a change-merged prototype dependency graph using a graph- 
union operation, shown in Figure 5.12. 

In building the prototype dependency graph, huildJ’DG adds an external vertex, 
EXT, to the prototype implementation graph, then for every vertex with no outputs, it 
creates an edge from that vertex to EXT. This is necessary to ensure that these terminal 
vertices are included in the slices, since slices are constructed based on edges not vertices. 
Then for every timer declaration in the prototype implementation, build J’DG creates an 
edge from every vertex which affects the state of that timer to every vertex which reads its 
value. 


The algorithm buildLPDG contains two loops. The first loop iterates through the 
vertices in the graph, and determines if the vertex has any outputs. For every vertex with 
no outputs, the algorithm then adds an edge to the graph from that vertex to the artificial 




Algorithm huUd-PDG{P : psdl^component) return prototypejdependency.graph 
G : prototype .dependency .graph] 

O : vertex] 

source, dest : id.sei] 

begin 

G ~ graph{P)] 

add external vertex, EXT] 

for every terminal vertex, O, add an edge from O to EXT] 
for every timer declaration in the implementation of P loop 
initialize source and dest to empty. 

add every vertex which affects the state of the timer to source] 
add every vertex which reads the timer to dest] 

add an edge to G from every vertex in source to every vertex in dest] 
end loop; 
return G] 
end buildJ^DG] 


Figure 5.7: Algorithm buildJ’DG. 

vertex EXT. The correctness of this loop can be established by showing that at the end of 
the loop, there are no vertices in the graph without output edges, except EXT. Since the 
loop cycles through all vertices in the graph and adds an output edge to the graph from any 
vertex which does not have one to EXT, this proof is trivial. 

The second loop iterates through the set of timer declarations, and builds two 
sets for each timer, source and dest. It then adds an edge to the graph from every vertex 
in source to every edge in dest. The source set contains all of the vertices using timer 
operations that affect the state of the timer. The dest set contains all of the vertices that 
read the value of the timer. 

To show correctness of this loop, we must show that at the end of each iteration 
through the loop, the graph contains all timer dependency edges associated with the timer 
declarations thus far encountered, and at the end of the loop, the graph contains all timer 
dependency edges associated with the timer declarations in the implementation. We do this 
by the following induction proof: 
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Basis: Since source and dest are initialized at the beginning of each iteration 
through the loop, they are empty before the first iteration, thus the graph contains no timer 
dependency edges before the first iteration. 

Induction Hypothesis: At the end of the fcth iteration, all timer dependency 
edges associated with the first k timer declarations are included in the graph. 

Induction Step: At the beginning of the k + 1st iteration of the loop, the source 
and dest sets are reinitialized to empty. The vertices that affect the state of the k + 1st 
timer are added to source, and the vertices that read the value of the k + 1st timer are 
added to dest. Now, for every vertex in source, the algorithm adds an edge to every vertex 
in dest. Thus at the end of the k + 1st iteration, the graph contains all timer dependency 
edges associated with the first k timer declarations, by the induction hypothesis, plus it now 
contains all timer dependency edges associated with the k+ 1st timer decleiration. Thus, we 
can conclude that for any number n of timer declarations, at the end of the nth iteration 
of the loop, the graph contciins all timer dependency edges associated with the first n timer 
declarations. □ 

The complexity of this algorithm is determined by the sum of the complexities 
of the two loops. Since the first loop iterates through all vertices in the graph, performing 
worst-case linear operations on each iteration, its worst case time complexity is 0{n^), where 
n is the number of vertices in the graph, excluding EXT. The second loop contains three 
inner loops that iterate through the vertex set of the graph. The first two of these inner 
loops contain worst-caise linear operations. The third inner loop contains another inner loop 
that could also possibly iterate through all vertices in the graph, making its worst case 
time complexity 0{n^). Thus, the worst case time complexity of the second outer loop is 
0{tTi^), where t is the number of timer declarations contained in the implementation and 
n is the number of vertices in the graph. The algorithm then contains two loops, one with 




complexity O(n^), and one with complexity O(in^), therefore, the worst case time complexity 
of huiliLPDG is 0{tn‘^). 

The next step in change-merging the graphs is finding out the parts of the mod¬ 
ified versions which are different from the base. This is accomplished using the algorithm 
af f ected-part, shown in Figure 5.8. This algorithm returns the set of edges in the modified 
version for which the slice of the modified version is different than the slice of the base ver¬ 
sion. First, each edge in the modified version is checked to see if it is the base version. If it 
is not, then it is added to the affected part. Next, the algorithm checks to see if the edge 
recieves input from different sources in the modified version than in the base version. If the 
sources are different, then the edge is added to the affected part. Finally, the algorithm adds 
any edge to the affected part which receives input via an edge already in the affected part. 

It is sufficient to include in the affected part of modified version, only those edges 
which are different in the modified cind base versions of the graph, and the edges which follow 
them. Any edge which precedes an affected edge will produce the same slice in both versions 
since slices are constructed backward from the edge. The correctness of a// ected.part is 
established by showing that, every in edge in Slice produces a slice which is different in both 
G and B. We prove this by an induction over the while loop. 

Proof : 

Basis; At the beginning of the first iteration of the loop. Slice gets one edge from 
E which is either in G and not in B, or is written to by a different set of vertices in G and 
B. This edge will certainly produce a different slice in the two graphs, so Slice contains only 
edges which produce different slices in G and B. 

Induction Hypothesis: After the first k iterations of the loop, every edge in 


Slice produces a different slice in G than in B. 






Algorithm af fected-part{G,B : prototypeJ,ependency.graph) 
return edgejset 
Slice, C,D,E : edge^et\ 
x,y : edge-, 
begin 

C -.= edges[B)-, 

D := edges{G); 

E := dif ference(D,C); 
for every edge i in Z> loop 

if sources{x) in G are different from the 
sowrces(i) in B then 
jwld X to E-, 
end if; 
end loop; 

while E not empty loop 

select and remove an edge x from E; 

add X to Slice-, 

for each edge y E D loop 

if X.destination E sources(y, G) then 
add y to E-, 
remove y from £>; 
end if; 
end loop; 
end loop; 
return Slice; 
end affecled^art; 


Figure 5.8: Algorithm affected.part 
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Induction Step: During the Irth iteration of the loop, every edge in G which 
follows the ith edge added to Slice in the data flow of G is added to E. At the beginning 
of the k + 1st iteration of the loop, one of the edges in E is removed from E and added 
to Slice. Since we know that any edge which follows an affected edge in the data flow will 
certainly produce a different slice in G and B, we know that this edge will as well. Thus by 
the induction hypothesis, all of the elements in Slice before this iteration produced different 
slices in G and B, and the current iteration adds an edge which produces a different slice 
in G and B, therefore after the k+ 1st iteration of the loop, every edge in Slice produces a 
different slice in G and B. Since E is a. finite set, and no edge already in Slice can be added 
back into E, the loop will terminate. D 

The complexity of affectetLpart is determined by the complexity of the loops 
inside. The first for loop iterates over all of the edges in the input graph, G, and adds any 
edge to E which is different in G and B or recieves input from different sources in G and 
B. The worst-case time complexity of this loop is 0{e * n), where e is the number of edges 
in G and n is the number of vertices in G. The second while loop iterates over all of the 
edges in E, which we know to contain at most the edges of G, and any edge which follows 
this edge in G is added to E. This makes the worst-case time complexity of this loop, O(e^). 
Therefore the worst-case time complexity of af fectetLpart is 0{e'^), where e is the number 
of edges in G. 

The next step in change-merging the graphs is constructing the part of the base 
version that is preserved in both of the modifications. This is done using the algorithm 
preserved^art shown in Figure 5.9. This algorithm loops over all of the edges in Base and 
checks to see if they are in the affected parts of either modification, or have been removed 
in one of the modifications. If the edge is not in either affected part and it is in both 
modifications, then the slice it produces is the same in all three versions and it is added to 
the preserved part. 
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Algorithm preserved.part{BASE, A, APA, B, APB : prototype J,eptndency-graph) 
return edge^et 
PP : edge-set := emptyset; 

begin 

for every edge E in edges{BASE) loop 

if not e e APA U APB and e € edges{A) 0 edges{B) 
then add e to PP\ 
endif; 
end loop 
return PP\ 
end preserved-part', 


Figure 5.9: Algorithm preserved^art 

Only those edges which appear in all three versions and are not part of either 
affected part are added to the preserved part. The correctness of this algorithm is established 
by showing that after each iteration of the for loop, PP only contains edges which will 
produce the same slice in all three versions. We offer the following proof: 

Proof : 

Basis: Before the first iteration of the loop, PP is empty. Since the slice with 
respect an empty edge is an empty graph, this slice is certainly the same in all three versions. 

Induction Hypothesis: After the first k iterations of the loop, every edge in PP 
produces the same slice in all three versions of the graph. 

Induction Step: During the k + 1st iteration of the loop, if the edge e is in the 
edge sets of all three versions, and it is not contained in an affected part, then it was not 
affected nor removed by either version, thus it is preserved in all three versions. Since after 
the fcth iteration of the loop, all of the edges in PP produced slices which were the same 
in all three versions, and the k + 1st iteration adds another which produces the same slice 
in all three versions, after + 1 iterations, every edge in PP produces the same slice in all 
three versions. Therefore the correctness of preaerved-part is established. □ 
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The complexity of preserved-part is determined by the complexity of the for loop. 
Since all of the operations inside of the loop are at worst 0{e) operations, and the loop 
iterates once for every edge in the base version of the graph, the worst-cast time complexity 
of preservedjpart is O(e^), where e is the number of edges in BASE. 

Once the preserved part of the base and the affected parts of both modified versions 
have been calculated, the slices produced by these sets can be change-merged into a single 
graph. The slices are constructed using the algorithm create.jlice shown in Figure 5.10. 
This algorithm takes a graph and an edge as input and constructs the slice backward from 
the edge, according to the definition for a slice given in Chapter IV, Section B.2. 


Algorithm create^lice{G : prototypejdependency.graph-, E : edge) 
return prototypejdependency-graph 
S : prototypejdependency.graph-, 

V -. vertexset; 
w : vertex-, 
begin 
if e in G 

then add e to 5; 

else return empty-graph-, 

for every vertex w in G loop 
if w writes to e 
then add u) to V; 
end if; 
end loop; 

while V not empty loop; 

select and remove vertex w from V; 
add w to S; 

add parents of u; to V if not in 5; 
add edges between parents and w to 5; 
end loop; 
return S; 
end createslice] 


Figure 5.10; Algorithm createslice 
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The correctness of create^lice is established by showing that the algorithm pro¬ 
duces a correct slice of G with respect to E, according to our definition of a slice given in 
Chapter IV. 

Proof : 

If e is not an edge in G, then createslice returns an empty graph, which is the 
correct slice of G with respect to e. If e is an edge in G, then e is added to the slice, and any 
vertex which writes to e is added to the set of vertices V.Then the algorithm iterates over a 
while loop as long as V is not empty. The correctness of the while loop is established by 
showing that at the end of every iteration of the loop, the slice S contains only the vertices 
and edges which affect the edge e, and after the last iteration of the loop, S contains all of 
the vertices and edges in G which affect the edge e. 

Basis: Before the first iteration of the loop, the only edge in S is e, and certainly 
every edge in S affects e. 

Induction Hypothesis: After the ith iteration of the loop, all of the edges and 
vertices in 5 affect the values written to e. 

Induction Step: During the k + 1st iteration of the loop, a vertex w is removed 
from V and added to S. Since only those vertices which write to an edge in S are in V, and 
only edges which affect the values written to e are in S by the Induction Hypothesis, we are 
guaranteed that tti is a correct addition to 5. So after the k + 1st iteration of the loop, S 
contains only edges and vertices which affect v.ilues written to c. 

Since V contains at most the number of vertices in G, and one vertex is removed on 
every iteration of the loop, we are assured that the loop will terminate. Since during every 
iteration, any edge which provided input to a vertex in S is added to S and every iteration 
adds any vertex which writes to an edge in S, we are assured that after the last iteration of 
the loop, all of the vertices and edges which affect the values written to e will be in the slice. 
□ 
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The time complexity of create^lice is determined by the two inner loops. The 
for loop iterates over the vertices of the graph one time. This makes the worst^case time 
complexity of this loop, 0(n), where n is the number of vertices in the graph. The while 
loop iterates over a set of vertices, however through all of the iterations of the loop at most 
each edge is visited once, making the worst-case time complexity of this loop 0(e), where 
e is the number of edges in the base version of the graph. Therefore, the worst-case time 
complexity of create^lice is 0{n -b e). 

Once the slices are constructed, they are merged using the function graphjmerge, 
shown in Figure 5.11. This is a very simple graph merging algorithm which uses successive 
calls to graph.union, shown in Figure 5.12 to combine the preserved part of the base with 
the affected parts of both modifications into a change-merged prototype dependency graph. 


Algorithm graph.Tnerge{Gl,G2,G3 : prototypejiependency.graph) 
return prototypejiependency.graph 
G : prototype.dependency.graph := emptyjpsdl.graph-, 
begin 

G := graph.union{Gl,G2); 

G graph.union{G,GZ)\ 

return G; 
end graphjnerge-, 


Figure 5.11; Algorithm graphjmerge 

The graph.union algorithm is used to combine two graphs into one. It accepts two 
prototype dependency graphs as input and adds the edges and vertices of one to the other. 

The algorithm graphjunion makes use of two successive union operations, and 
union operations are very well defined. Therefore, the correctness of graph.union is easily 
established. 

The complexity of graph.union is determined solely by the complexities of the 
set union operations, which are linear in the worst case. Therefore, the worst case time 
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Algorithm graphjunion{Gl., G2 : prototype.dependency-graph) 
return prototype-dependency -graph 
G ; prototype-dependency -graph := empty-psdl-graph-, 
begin 

G.vertices := vertices{Gl) U vertices{G2)-, 

G.edges := edges(Gl) U edges(G2); 
return G; 
end graph-union; 

Figure 5.12: Algorithm graph-union 

complexity of graph-union is the sum of the complexities of the two union operations, or 
0(e + n), where e is the number of edges in the largest of G?1 and G2, and n is the number 
of vertices in the largest of G\ and G2. 

The correctness and complexity of graph-merge depend solely on the correctness 
and complexity of graph-union, which have previously been established. Thus, graph-merge 
is a correct algorithm with worst-case time complexity of 0(e n), where e and n are the 

number of edges and vertices in the largest input graph. 

Once the graphs have been change-merged, the remainder of the implementation 
parts must be change-merged. The stream declarations and the timer declarations are 
change-merged using the functions mergestreams and mergeJtimers, shown in Figures 
5.13 and 5.14, respectively. Then the control constraints are change-merged using functions 
appropriate to their map type. These algorithms are shown in Figures 5.15 through 5.26. 

2. Change-Merging the Stream and Timer Declarations 

The stream and timer declaration parts are modeled as sets, so change-merging 
them is done using common set operations. In mergestrearns, the two for loops construct 
the three pieces of the change-merging equation for sets, {A—Base), (AnB), and (B — Base). 
The correctness and complexity of mergestreams are identical to those of merge-states. In 
mergeJtimers, the three pieces of the change-merging equation are constructed separately 




and combined to provide the result. The correctness and complexity of this algorithm is 
identical to that of merge.id.sets. 


h\gOT\i\immeTge.streams[BASE, A, B : type.declaration) return iype.declaration 
MERGE ■. type.declaration- 
begin 

MERGE := empty.typejdeclaration\ 
for every stream s in A loop 

if s is not in BASE and s is not in B then 
add 5 to MERGE] 

if s is in B then 
add to MERGE] 
end if; 
end loop; 

for every stream s in J5 loop 

if s is not in BASE and s is not in A then 
add to MERGE] 
end if; 
end loop; 
return MERGE] 
end mergejstreams] 


Figure 5.13: Algorithm mergejstreams 


Algorithm mergeJimers(BASE,A, B : idjset) return id.set 
begin 

Calculate A — BASE. 

Calculate B - BASE. 

Calculate AP\B. 

Return {A - BASE)\J{AC[B)\^{B - BASE). 
end mergeJtimers] 


Figure 5.14: Algorithm mergeJtimers 

3. Change-Merging the Control Constraints 


Change-Merging the Control Constrciints is accomplished by a series of algorithms 
that implement the models defined in Chapter III, Section D. Their correctness is established 
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by their conformance to the mathematical models. Each one of these algorithms has worst- 
case time complexity of C)(n), except mergeJriggerjmaps and mergeJ,imer.opjrnaps, where 
n is the number of vertices in the largest input prototype, mergedriggtrjmaps has worst- 
C2ise time complexity of 0(ns'^), where n is the number of vertices in the largest input 
prototype and s is the largest number of streams read by an operator in the prototype. 
mergeJtimerjops has worst-ccise time complexity of where n is the number of vertices 

in the largest input prototype and t is the largest number of timer operations in the prototype. 
Since these algorithms all execute independently, the worst-case time complexity for the 
entire control constraints section is C?(ns^-|- nO). 


Algorithm mergeJriggerjnaps{VERTS : id^et; BASE, A, B : triggerjmap) 
return trigger jmap 
MERGE : triggerjmap\ 
opJd : psdlJd; 

base-trig, a-trig,b-trig,mergeJ.rig : trigger: 
begin 

for every opJd in VERTS loop 
retrieve baseJrig from BASE-, 
retrieve ajtrig from A; 
retrieve bJrig from J5; 

mergeJrig := mergeJriggers{baseJrig,aJrig,bJrig); 
bind mergeJrig to opJd in MERGE-, 
end loop; 
return MERGE-, 
end mergeJriggerjmaps-. 


Figure 5.15: Algorithm mergeJriggerjmaps 

There is also an informal description of the implementation part that must be 
change-merged. The implementation descriptions are change-merged using the mergeJext 
function shown in Figure 5.6. 


100 



Algorithm mergeJriggers{BASE,A,B : trigger) return trigger 
MERGE ; trigger-, 
streams : id,et-, 
begin 

if BASE — A then 
if BASE = B then 

MERGE.tt ~ BASE.tt 

MERGE.streams := mergeJd-sets(BASE.streams, A.streams, B.streams)-, 
return MERGE-, 
else return B-, 

else if BASE = B then 
return A; 
else i{ A = B then 
return A; 
return conflict; 
end if; 
end if; 
end if; 

end merge-triggers-. 


Figure 5.16: Algorithm merge-triggers 


Algorithm merge-exec-guard-maps{VERTS : id-set-, BASE, A, B : exec-guard-map) 
return exec.guardjnap 
MERGE : exec-guard-map; 
opJtd -. psdlJd-, 

hase.eg, a.eg, b.eg, merge.eg : expression: 
begin 

for every opJ,d in VERTS loop 
retrieve base-eg from BASE; 
retrieve ajeg from A; 
retrieve b-cg from B; 

merge-eg := merge.expressions{base-eg, a.eg, b.eg); 
bind merge.eg to opJd in MERGE; 
end loop; 
return MERGE; 
end merge.exec-guard-maps; 


Figure 5.17: Algorithm merge.exec.guard-maps 
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Algorithm merge.expressions{BASE,A,B: expression) return expression; 
begin 

if equal{BASE,A) then 

if equal{BASE, B) then return BASE else return B; end if; 
else if equal{BASE, B) then return A; 
else if equal{A,B) then return A; 

return conflict; 
end if; 
end if; 
end if; 

end merge-expressions; 


Figure 5.18: Algorithm merge-expressions 


Algorithm merge.output-guard.maps{VEIiTS : id^et;BASE,A,B : out.guard.map) re¬ 
turn out.guardjnap 
MERGE : out.guard.map; 
opjd : psdl.id; 

base.og, a.og, b.og, merge.og : expression: 
begin 

for every opjd in VERTS loop 
retrieve base.og from BASE; 
retrieve ajog from A; 
retrieve b.og from B; 

merge.og := merge.expressions{base.og, a.og, b.og); 
bind merge.og to opJid in MERGE; 
end loop; 
return MERGE; 
end merge.output.guard.maps; 


Figure 5.19: Algorithm merge.output.guard.maps 
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Algorithm merge.excepJ,riggtrjmaps[VERTS : id-set; BASE, A, B : excepjrigger.map) 
return txcepj.rigger jnap 
MERGE : excepJ.riggerjmap; 
opJd : psdlJd; 

base.e.t,a-et, b.et,Tnerge^et : expression: 
begin 

for every opJd in VERTS loop 
retrieve base.et from BASE-, 
retrieve ajet from A; 
retrieve b-tt from B', 

merge.et := merge-expressions{base-et,cuet,buei)-, 
bind merge.et to opJd in MERGE-, 
end loop; 
return MERGE-, 
end merge.excepJriggerjTiaps-, 


Figure 5.20: Algorithm merge.txcepAriggerjmaps 


Algorithm merge.timerjopjnaps{VERTS : idjset-,BASE,A,B : timer.op.map) return 
timer jopjmap 

MERGE : excep.trigger.map; 
opJd : psdl.id; 

base.set,a.set,b.set,merge.set : expression: 
begin 

for every opJd in VERTS loop 
retrieve base.set from BASE; 
retrieve a_se< from A; 
retrieve bjset from B; 

merge.set := merge.timer.opjset{base.set, a.set, b.set); 
bind merge.set to op.id in MERGE; 
end loop; 
return MERGE; 
end merge.timerjopjnaps; 


Figure 5.21: Algorithm merge-timerjopjmaps 
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Algorithm mergeJimer-op.sets(BASE,A,B : iimer-op^et) return timer.op^et 
MERGE : timer.opset-, 
tjop : timer.op-, 
begin 

for every tjop in BASE loop 
if member{tjop, A) then 
if member{tjop, B) then 
add{tjop, MERGE); 
end if; 
end if; 

for every tjop in A loop 

if notmember{t.op, MERGE) then 
if member(tjop, B) then 
add{tjop, MERGE); 
end if; 
end if; 

for every tjop in B loop 

if notmember{tjop, MERGE) then 
if member{tjop, A) then 
add{tjop, MERGE); 
end if; 
end if; 

end loop; 

return MERGE; 
end merge.timerjop^eis; 


Figure 5.22; Algorithm merge.timerjop.sets 



Algorithm mergejperiod{VERTS : id^et; BASE, A, B : timing-map) return timing-map 
MERGE : timing-map- 
opjd : psdl-id] 

base-val, a-val, b-val, mergt-val: millisec := 0; 
begin 

for every op-id in VERTS loop 
retrieve bast-val from BASE] 
retrieve a-val from A; 
retrieve b.val from 5; 

mtrgt-val := merge-timing jdata{hase-val, a-val, b-val); 
bind mergt-val to op-id in MERGE-, 
end loop; 
return MERGE-, 
end merge-period] 


Figure 5.23: Algorithm mergejperiod 


Algorithm merge./■wjorj7irt{VERTS : idjset-,BASE,A,B : timing-map) 
return timingjnap 
MERGE -. timingjmap-, 
opJd : psdlJd-, 

base-val, o-val, b-val, merge-val : millisec := 0: 
begin 

for every opSd in VERTS loop 
retrieve basejval from BASE] 
retrieve a-val from A] 
retrieve b.val from B] 

merge.val := mergejnet{base.val,a.val,b.val)] 
bind merge.val to op.id in MERGE] 
end loop; 
return MERGE] 
end merge.fwjorjmrt] 


Figure 5.24: Algorithm merge./w.or.mrt 
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Algorithm merge-min.calLper{VERTS : idset, BASE, A, B : timingjnap) 
return timingjmap 
MERGE : timingjmap-, 
opJd : psdlJd', 

basejval, a.val, b-val, merge^val: millisec := 0: 
begin 

for every opJd in VERTS loop 
retrieve basejual from BASE-, 
retrieve ajual from A; 
retrieve bjual from B-, 

mergejvalmergejmcp{basejval,a.val,bLval)-, 
bind mergejval to opJd in MERGE-, 
end loop; 
return MERGE-, 
end mergejmin-calljper-, 


Figure 5.25: Algorithm merge.min.call^er 

4. Analysis of Implementation Change-Merge 


Change-merging the implementation of the top level component requires four main 
operations; change-merging the graphs, change-merging the stream declarations, change- 
merging the timer declarations, and change-merging the control constraints. 

Change-merging the graphs requires that each graph be converted to a PDG using 
build-PDG which requires 0{tn^) time, where n is the number of vertices in the graph and 
t is the number of timers declared in the implementation. 

After the prototype dependency graphs are constructed, the affected parts of each 
modification are constructed using affected-part which has worst-case time complexity 
C)(e*), where e is the number of edges. Then the preserved part is constructed, and it 
has worst-case time complexity C?(c*). 
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Algorithm mtrgejmcp{BASE,A,B : millisec) return millistc 
AJ)1FFJASE,BJ)IFFJASE,AJNT-B : millisec- 
begin 

ii A> B then 
AJNT^ ;= B; 
else AJNT-B := A- 
end if; 

if BASE > A then 
AJ)IFF^ASE := T; 
else AJ)1FFJASE := A; 
end if; 

if BASE > B then 
BJ)IFFJASE := T; 
else BJ)IFF^ASE := 5; 
end if; 

if A-DIFF^ASE > AJNTJ then 

if AJDIFFJASE > BJ)IFF^ASE then 
return AJ)IFFJBASE\ 
else return BJDIFF-BASE; 
end if; 

else if AJNTJ > BJ)IFF^ASE then 
return AdNT-B', 
else return BJ)IFFJBASE; 
end if; 
end if; 

end mergcrncp; 


Figure 5.26: Algorithm mergejncp. 
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After all three of the pieces required for change-merging the graphs have been built, 
then they must be change-merged using graphjnerge, which contains two successive calls 
to graph-union, which we already know requires worst-case 0{n + e) time. Therefore, the 
worst-case time complexity of change-merging three graphs is: 

0{tn^) + O(e’) -f C?(e") + O(e^) -b e?(n -f e) = 0{tn^ + e^) 

The edges in the graph almost always outnumber the vertices, so we call this O(e^). 

The correctness of the Implementation Change-Merge is established by the cor¬ 
rectness of the individual parts. The complexity of the Implementation Change-Merge is 
dominated by the complexity of the change-merging of the graphs, so the worst-case time 
complexity of the Implementation Change-Merge is O(e’). 

D. CREATING THE CHANGE-MERGED PROGRAM 


The last algorithm used in this change-merging tool is build.prototype, shown in Figure 
5.27. This algorithm takes the change-merged graph and removes the artificial timer edges 
and external vertex. It then sets the change-merged graph in the change-merged prototype. 


Algorithm build.prototype{P : in out psdl .component-, G : prototype.dependency .graph) 
A : psdl.graph-, 
begin 

assign G to A; 
remove external vertex; 
remove timer dependency edges; 
set.graph{A, P); 
end build.prototype] 


Figure 5.27: Algorithm build.prototype 

The timer dependency edges are removed by iterating through the edges of the graph 
and removing the appropriate edges. This requires iteration over the edges of the change- 
merged graph, making the worst-case time complexity of this algorithm 0(e). 
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E. ANALYSIS OF THE CHANGE-MERGING ALGORITHM 

The correctness of the algorithm changejmerge is established by the correctness of 
the individual parts. Since these individual algorithms are executed independently of one 
another, there are no dependencies between them, other than those already discussed. The 
complexity of this algorithm is calculated by adding the complexities of the individual parts. 
It is easy to see that the complexity is dominated by change-merging the graphs in the 
implementation part, which requires 0[e^) time, where e is the number of edges in the 
largest graph. Therefore, the worst-cMe time complexity of the entire algorithm is 0{e^). 
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VI. CAPS MERGE TOOL 


In this chapter we describe an implementation for a change-merging tool resulting from 
this effort. The tool has been almost fully implemented and can easily be integrated into the 
CAPS Prototyping Environment. It is invoked through the Manager’s Interface and provides 
a substantially beneficial tool for effective management of large software prototypes. Section 
A of this chapter describes the requirements for the tool. Section B provides the instructions 
for using the tool. Section C describes the testing performed on the tool. 

A. REQUIREMENTS 

The requirements for this tool are divided into three parts; interface, functioneility and 
conflict reporting. Each of these parts are discussed separately in the subsections that follow; 

1. Interface Requirements 

a.' Interface must be consistent xnith other CAPS interfaces: CAPs uses a menu- 
driven interface at the top level and windows with selection lists and pushbuttons at lower 
levels. To be consistent, a pushbutton type interface was required for the change-merge tool 
as well. 


b. User must be able to choose any prototype currently in the working directory. 
The interface should provide a list of the prototypes currently in the user’s working directory, 
and the capability for the user to select one of these prototypes. 

c. User must be able to select different versions and assign them to the different 
merge parameters by pushbutton: After the prototype has been selected, the interface should 
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provide a list of the current versions of the prototype. The user should then be able to select 
each version by clicking with the mouse, and assign the selected version to one of the merge 
parameters, base, versiorua or version.b, by pushing an assign button. 

d. User should be satisfied that the selection made has been assigned to the correct 
parameter. The interface should provide visual reinforcement that the selection made has 
been cissigned to the correct parameter by showing the selected version in a window labeled 
with the parameter name. 

e. User should be able to initiate the merge tool by pushing a button: The interface 
should provide a button labeled “merge” which, when pushed, will call the merge tool for 
the parameters given. 

f. User should be notified when merge is complete: The interfcice should provide 
a pop-up window that alerts the user that the merge is complete. The result of the merge 
should be printed in a window labeled “result”. 

g. User should be notified if a conflict occurs: The interface should provide a pop-up 
window that alerts the user that a conflict has occurred during the merge. 

h. User should be able to commit the result to the design database directly from the 
merge interface: A pushbutton should be provided that allows the manager using the tool 
to commit the result of the merge to the databcise, even if conflicts have occurred. 

2. Functionality Requirements 

a. Tool must be able to retrieve the three versions of the prototype when provided 
only the paths to their locations: The interface will provide the full directory names for each 
of the input versions as input to the tool. The tool must be able to combine all of the PSDL 
source files in each of the version directories into one single file and call the PSDL parser to 
convert the text version of the prototype into an ADT representation of the prototype. 
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b. Tool must call the PSDL expander to provide fully expanded PSDL programs 
as input to the change-merge procedure: The PSDL expander is a tool which takes a multi- 
leveled prototype and converts it into a flat prototype with only one composite component. 

c. Tool must change-merge the three versions of the prototype according to the 
models provided by this dissertation: The change-merge tool must be able to retrieve the 
composite component of each version, and perform the change-merge operation using these 
three components as input. It then must provide a new composite component for the merged 
prototype. The atomic components will then be added to the merged prototype according 
to which version supplied those components to the merged implementation graph. 

d. Tool mxist split the final version of the prototype into separate files for each of 
the component implementations and specifications: The tool must be able to take the merged 
prototype 2ind output it into separate files in the result directory. Each file should contain 
either the specification part or implementation part of one component. If the component 
is the composite component, then the name of the file will be “prototype-name.imp.psdl” 
or “prototype.name.spec.psdl”, depending on whether it contains the implementation or 
specification part of the component, and where ‘^prototype-name” is the name of the com¬ 
posite component. If the component is an atomic component, then the name of the file 
will be “prototype-name.componenLnamel.imp.psdl” if it contains an implementation or 
“prototype-name.componenLname.spec.psdT if it contains a specification, where “compo- 
nent.name” is the name of the atomic component. 

3. Conflict Reporting Requirements 

a. Tool must report to the user where in the merged component a conflict has 
occurred: In each piece of the change-merged program where a conflict has occurred, the 
tool must place a flag indicating to the designer where the conflict occurred. This will 
prevent the user from having to search for the conflict in order to resolve it. 
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b. Tool must provide at least a partially change-merged program in thf 
all conflicts: The tool will provide the most change-merged program possible \vh 
conflict has occurred. Conflicts in one part of the program should not affect other 
the program which are not dependent on the part with the conflict. 

B. USING CAPS MERGE TOOL 

To invoke the CAPS merge tool, select the merge prototypes option from the n 
interface. The CAPS merge tool window will be displayed as shown in Figure 6.1. 
of currently available prototypes will be displayed in the prototypes box at the low 













1. Selecting Prototypes and Versions 

To select a prototype, click the left mouse button over the name of the prototype 
to be selected. Clicking twice on the same prototype will deselect the prototype. After 
selecting a prototype name, a list containing all of the versions of the selected prototype will 
appear in the versions box at the lower right of the merge tool window, as shown in Figure 
6.2. To select a version, click the left mouse button on top of one of the versions. Again, 
double clicking on the same version will deselect the version. 



Figure 6.2: CAPS Prototype Merge Tool Interface with List of Versions 

2. Performing the Merge Operation 

To perform a merge, three versions must be selected and assigned to the merge 
parameter boxes. To assign parameters, first select the version, then click the left mouse 
button on the “assign” button next to the parameter to be assigned. Figure 6.3 shows the 
window after all three parameters have been assigned. Changing a parameter assignment is 
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done by selecting the correct version and clicking on the “assign” button again. Every push 
of the “cissign” button reassigns the parameter to the selected version. To clear all of the 
parameter eissignments, use the clear button located on the right center of the window. 



Figure 6.3: Assignment of Parameters 


When all of the parameters have been assigned, the “merge” button located on the 
right side of the window must be pushed. This will invoke the change-merge tool. When the 
change-merge tool has completed its execution, one or two windows will appear on the screen. 
The “merge complete” window, shown in Figure 6.4, will always appear after execution of the 
tool. If a conflict was detected during the change-merge, the “conflict notification” window, 
as shown in Figure 6.5, will also appear. The manager can either choose to keep the result 
and manually resolve the conflicts or abandon the result and start again. 



Figure 6.4; Merge Complete 
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Figure 6.5: Notification of Conflict 

3. Commit Merge 

Once the merge has been completed, the manager has to specifically commit the 
result to the design database. To commit the merged result, the manager clicks the left 
mouse button on the “commit merge” button on the right side of the CAPS Merge Tool 
window. A new version number will be assigned to result and it will be added to design 
database as a permanent part of the prototypes configuration. 

At this point, the manager can choose to perform another merge operation or exit 
the tool. If another merge is desired repeat the process described above as many times as 
desired. To exit the CAPS Merge Tool, click the left mouse button on the “exit” button at 
the bottom of the window, and control will be returned to the CAPS Manager Interface. 

C. TESTING 

We tested the change-merging tool by applying it to a series of sample prototype projects 
each testing a different part of the tool. These projects included real prototypes which 
were developed by students in the CAPS Research Team as well as examples constructed 
specifically for this test. The largest of these prototypes is the Command and Control System 
described in [Ref. 38]. The implementation for this prototype contains 27 vertices and 35 
edges with a full range of control constraints. Four modified versions of this prototype were 




prototype were created, and the change-merge tool was applied to different combinations of 
the four, each testing a different part of the tool. 

Timing tests were conducted to provide a realistic assessment of the speed with which 
the tool would operate. During the test it was determined that the time required to process 
each of the input files (combining the multiple files into one, parsing the input files, and 
expanding the prototype to a flat graph) took a significant amount of the time for the 
system to run. In the case of the Command and Control prototype, the system took on 
average six seconds to process each file and 25 seconds to change-merge them. In the case 
of the smaller prototypes, the times were significantly less. 

Since the current implementation is not as efficient as an optimal one outlined by the 
algorithms in Chapter V, we can expect a significant speedup for the optimal implementation. 
In each test of the change-merge tool, the results were exactly as expected. The tool produced 
conflicts whenever expected and correct results when they were possible. 
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VII. CONCLUSION 


A. WHAT WE HAVE ACCOMPLISHED AND WHY IT IS IM¬ 
PORTANT 

The purpose of this research wjis to provide a computer-aided method for combining 
and integrating the contributions of different people working on the same prototype. It is 
commonly known that one of the most time consuming and problematic parts of developing 
large software systems is combining independently developed pieces of the system and en¬ 
suring they do not conflict. We developed a computer-aided method for merging changes to 
a prototype which will always produce a correct result or report a potential conflict. Using 
this method provides a prototype development manager with the ability to assign different 
development tasks for the same prototype to different members of the development team 
and be assured that the pieces can be integrated together after their completion in a safe 
manner. This method will either produce a change-merged prototype that is correct with 
respect to the different updates or it will notify the manager that a conflict has occurred. 

We found a solution to an analog of this problem in previous work done on integrating 
different versions of while programs at the University of Wisconsin [Ref. 28, 42, 29]. The 
main difference between their method and ours is that while programs are very different 
from data flow programs. Data flow programs are inherently parallel and non-deterministic, 
and the claiss of enhanced data flow programs used in PSDL also include hard real-time 
constraints. 

We proved our method correct by observing that slices of prototypes which isolate a 
portion of the prototype’s behavior will always behave the same in any prototype where 
they are well defined slices. Using the Slicing Theorem in Chapter IV, we were able to show 
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that as long as the slice of the merged version of the prototype with respect to the affected 
parts of each modification was the same cis the same slice of the modification, the changes 
introduced by that modification were preserved by the method. 

To prove this theorem, we had to develop a computational model of the PSDL language. 
Chapter IV provides a detailed development of the model of the language from defining 
the behavior on a single stream in the prototype to constructing the behavior of the entire 
prototype from the behaviors of the individual operators in the prototype. This construction 
is possible because we showed in the Independent Operator Lemma in Appendix B that the 
possibility function for an operator is not determined by the context in which it is placed. 
As long as the operator is given the Scime input, it will behave in precisely the same way in 
any prototype. 

From the model, we developed an algorithm which can perform the change-merge in 
C?(e*) time and 0{n}) space, and an implementation which provides a working change- 
merge tool to be used in the Computer-Aided Prototyping System. The algorithm and tool 
demonstrates the feasibility of our method for problems of practical size. 

During the course of this research, we also proposed an improved method for slicing 
and merging while programs which provides a strictly more accurate method than previously 
defined methods. No proof of this method is provided however. That will be left to future 
work. 

B. WHAT STILL NEEDS TO BE DONE 

We couldn’t possibly solve all of the world’s problems in the short amount of time pro¬ 
vided, so there are stiU many out there to be tackled. Some of the problems that we intend 
to continue working on are providing a method for change-merging different versions of an 
abstract data type written in PSDL. Our method will currently handle the operator imple¬ 
mentations for ADTs, but fails to provide a method for integrating the data representations. 
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Another area which needs consideration is the area of merging programs in high level 
programming languages, like Ada. In prototyping large systems, it is very important to auto¬ 
mate as many of the development tasks as possible to minimize the drain on resources caused 
by monotonically decreasing budgets. One of the first tasks to be finished is completing the 
formalization of the conditional program merging we proposed in Chapter III. 

Another area that warrants further study is in further improving the conflict detection 
methods used in change-merging. Automatic conflict resolution tools would provide project 
managers with an even greater degree of confidence in the change-merging tools. 
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APPENDIX A 


FORMAL DEFINITIONS 


This appendix contains formal definitions of the types, properties, and functions used 
in our behavioral model of PSDL. 

1. TYPE DEFINITIONS 

a. data_tuple{t: type} = 

tuple{value : t, operator : op Ad, write Jime : real, read Jime : real) 

b. trace{t; type) = ae9uence{data_tuple{t}} 

c. stream_behavior{t; type) = set{trace{t}} 

d. trace.tuplelP : prototype} = tup/e{trace{type{s} :: s e ^^(^’)}} 

e. prototype_behavior{P : prototype} = set{trace_tuple{P}} 

f. incremental_trace_tuple{t : writeJime] = 

tup/e{data_tuple{type{s} SUCH THAT s € E{P)} 

:: data.tuple.writeJime = <} 

2. INVARIANT DEFINITIONS 

We cissume that the implementation of an operating system where a PSDL prototype 
is being executed will guarantee mutual exclusion when two operators executing in parallel 
wish to write to the same strecim at the same time. Because we assume this control on write 
access for data streams, we can guarantee the following invariant is true for all data streams 
in a PSDL implementation. 
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a. monotonic_time(t ; trace) 

ALL (i, j-. nat SUCH THAT l<i<j < length(<) 

:: t[i].writeJime < t\j].writeJ.iTne 

- The write times in a trace Me monotonicaJly increasing. 

Since an operator writing to a data stream had to read from its input streams before 
it completes execution, we can guarantee that any data tuple in a trace will satisfy the 
following invariant: 

b. firingjnvariant(t : trace) 

ALL (i: nat SUCH THAT 1 < f < length(t) 

:: {t[i].readJime < t[i].wrUeJ.ime) \ {t[i].rea(LtiTne = t[i].write.tiTne = 0)) 

- The write time in any data tuple is strictly greater than the read time 

- in that data tuple, unless it is the initial data tuple. 

If an operator receives input from a feedback loop, then the vertex associated with that 
operator is on a cycle in the PSDL implementation graph. It is necessary to know that 
an operator is on a cycle because this information affects the possibility function of that 
operator. 

c. on^.cycle(o: opJd) 

- o provides output to a feedback loop which in turn provides input to o. 


3. FUNCTION DEFINITIONS AND PROPERTIES 
a. Merging Traces 

In PSDL, it is possible for more than one operator to write into the same stream. 
If this is the case, each of these operators independently writes a sequence of data tuples 
to that stream. These sequences merge to form a single trace for the stream. The function 
merge specified below shows that this combination of sequences is well-defined. Propositions 
4 through 8 state properties about the function merge which are needed for our discussion 
of possibility functions in chapter IV. 
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merge(il,t2 : trace SUCH THAT ALL (i, j: nat :: tl[i].writeJ.ime ^ t2[j].writej.ime) 
REPLY (t3 : trace) 

WHERE monotoiiic_time(i3) & firing_invariant(<3) & 

length(<3) = length(<l) + length(t2) — 1 &: tl[0] = i2[0] = t3[0] 

— Every trace contains an initial data.tuple with index zero. 

ALL (i: nat SUCH THAT 1 < i < length(<3) 

:: SOME(j: nat:: (t3[i] = <l[y] &: 1 < j < length(tl)) 

I (<3[i-] = t2[j] A: 1 < i < length(t2)))), 

ALL (i: nat SUCH THAT 1 < i < length(n) 

:: SOME(i: nat:: <3L7] = /l[i] & 1 < i < length(<3))), 

ALL (i: nat SUCH THAT l<i< length(t2) 

:: SOME(j: nat:: t3[y] = <2[i] & 1 < j < length(t3))) 

Proposition 4 merge is well-defined 

merge is a total, single-valued function over the specified domain. 

Proof 

Let <1 and <2 be traces on a stream SUCH THAT 
Vt, j e N,tl[i].u;rt<eJime ^ t2[j].writeJ.ime. 

Suppose <3 = merge{t\,i2) and <4 = merge{t\,t2) SUCH THAT <3 ^ f4. 

Since <3 and f4 are both valid results of merge{t\,t2), we conclude that they both 
satisfy monotonicJime and length{t3) = length{t4) = length{tl) + length{t2) — 1. 

Since f3 ^ <4, 3i e N 11 < length{t3) SUCH THAT 
<3[t].uo/ue / t4[i].value or <3[t].operafor ^ f4[i].operator or 
<3[i].iortteJime ^ <4[t].tort/ej2me or <3[t].readJtme / t4[i].rea<L<ime or 

But, by the definition of merge, every element in both <3 and <4 are elements 
of either fl or <2, which have no common write.times, and since both t3 and <4 satisfy 
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monotonicJime, there is only one way to combine the elements of tl and t2 into a single 
trace that satisfies monotonicJ-ime. Thus t3 = tA, and we have a contradiction, merge is 
well-defined. □ 

Proposition 5 merge satisfies monotonicJime 

If monotonic Jime{t\) and monotonicJime{t2) then m(motonicJime(merge{t\,t2)). 

Proof 

We assume that il and t2 have no common write times, and that monotonicJime 
is satisfied for both <1 and t2. Let <3 = merge{tl,t2). We show <3 satisfies monotonicJime 
by induction. 

Beisis: length{tZ) = 1 

Since every trace has a data_tuple with index zero, then <3 is the trace with only 
an initiaLdata_tuple, and monotonicJime is satisfied. 

Induction Step: Assume that tZ \ k satisfies monotonicJime. Since tl and t2 
satisfy monotonicJime, and they do not contain data.tuples with the same write times, we 
know that no matter which of tl and t2 the k + 1st element of t3 comes from, its write 
time will be greater than tin*. So, we can conclude that the -|- 1 element of t3, when 
added will have writeJime greater than t3[A:]. Since t3 | k satisfies monotonicJime, and 
t3[k -|- l].u;rite-t:me > t3[A:].tnrite.ttme, we conclude that monotonicJime{tZ) is satisfied. 
□ 
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Proposition 6 merge satisfies firing.invariant 

If firing.invariant is satisfied for both fl and t2 then firing.invariant is satisfied 
for merge(tl,t2). 

Proof 

We assume that tl and t2 have no common write times, and that firing.invariant 
is satisfied for both <1 and t2. Let <3 = merge{tl,t2). We show firing.invariant{t3) by 
induction. 

Basis: length{t3) = 1 

Since every trace has a data_tuple with index zero, then <3 is the trace with 
only an initial data tuple, and two = fro = 0 by the definition of initial data tuples. So 
firing.invariant{t3) is satisfied. 

Induction Step: Assume that f3 | k satisfies firingjnvariant. Since fl and f2 
satisfy firingjnvariant and each element of f3 is also an element of fl or f2, we know that 
no matter which of fl and f2 the k + 1st element of f3 comes from, tw^+i > fr^+i. We can 
conclude therefore that firingJnvariant{t3) is satisfied. □ 

Proposition 7 merge is commutative. 

merge(tl,t2) = merge{t2,tl) 

Proof 

We assume that fl and f2 have no common write_times. We further assume that 
since fl and f2 are traces, they both satisfy the trace invariants monotonic.time and fir¬ 
ing.invariant. 

We show that the merge function applied to f 1 and f2 satisfies these conditions and 
the length of the result is exactly the same regardless of the order of the parcuneters. 
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Let <3 = merge{tl,t2). 

Then length{t3) = length{merge{t\,t2)) = length{tl) + length{t2) — 1. 

But, since + is commutative, then 

length{tl) + length{t2) — 1 = length{t2) + length(tl) — 1 = length{merge{t2,tl)). 

We know by Proposition 5 that monotonic dime is satisfied for both merpe(tl,t2) 
and merge[t2,t\). We know by Proposition 6 that firing .invariant is satisfied for both 
merge{tl,t2) and merge(t2,tl). Therefore merge is commutative. □ 

Proposition 8 merge is associative. 

If tl, t2 and t3 each satisfy monotonicdime and firingjnvariant, and they have 
no common times, then merge{t\,merge{t2,t3)) = merge(merge{t\,t2),t3). 

Proof 

We assume that <1, t2 and t3 have no common writeJimes. We further assume 
that since tl, t2 and t3 are traces, they all satisfy the conditions monotonicdime and 
firingjnvariant. 

Let t4 = merge(tl,merge{t2,t3)). 

Then length{t4) = Iength{merge{t\,merge{t2,t3))) — 
length{tl) + length(merge(t2,tZ)) — 1 = 
length{tl) + {length(t2) + length{tZ) — 1) — 1 = 
length(U) + length{t2) + length(tZ) — 1 — 1 = 

{length{tl) + length{t2) — 1) + length{tZ) - 1 = 
length{merge(tl,t2)) + length{tZ) — 1 = 
length{merge{merge(tl, t2), tZ)). 

So the lengths of merge{tl,merge(t2,tZ)) and merge{merge{tl,t2),tZ) are the 
same. We know by Proposition 5 that monotonicdime is satisfied for both merge{t2,tZ) and 
merge{t\,t2). Thus using the same logic, we can conclude that monotonicdime is satisfied 
for merge{tl,merge{t2,tZ)) and for merge{merge{tl,t2),tZ). We know by Proposition 6 
that firingjnvariant is satisfied for both merge{t2,tZ) and merge{tl,t2). Thus using the 
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same logic, we can conclude that firingJtnvariant is satisfied for merge[i\,merge.{t2,tZ)) 
and for merge.{merge{t\,t2)^tyj. Therefore merge is associative. □ 

b. Other Functions 

This section contains definitions for other functions used to construct the possibility 
functions for prototypes. 


(1) ffi 


The “0” function extends trace.tuples by appending incrementaLtrace.tuples 
to them. It takes as input a trace-tuple T and an incrementaLtrace_tuple.set S. The output 
of the function is a set of trace.tuples where the prefix of each element in the set is T, and 
the remainder of each element is an element of S. 

“0”(r: trace-tuple, 5; incrementaLtrace_tuple_set) 

REPLY (D: trace.tuple_set) 

ALL («: trace-tuple SUCH THAT tt e D 

:: SOME(d; incrementaLtrace_tuple SUCH THAT d E S 
:: it = append(r, d))) 


(2) A 


The A function is used to select incrementaLtrace.tuples which have a partic¬ 
ular write.time. 

A{t: time, 51: incrementaLtrace_tuple_set) 

REPLY 52: incremental_trace_tuple_set 

ALL {D: incremental-trace-tuple SUCH THAT D e 52 
:: ALL(d: data.tuple SUCH THAT deD 
:: d.writeMme = t )) 
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(3) P 


The p function provides the earliest possible time that an operator can read 
its input streams based on its output history. If the operator is on a cycle in the graph, 
then it must complete every firing to include writing its output streams before it can read 
its input streams. If it is not on a cycle, then it does not have to wait for a previous firing 
to be complete before it can read its input streams agciin. 

p[T-. trace_tuple, o: op Jd) REPLY t: time 
SOME(s: stream-set SUCH THAT s C 0{o) 

ALL(t: trace SUCH THAT t G T. 

:: WHEN on-a.cycle(o) t > T[length{r) — l].writeJ,ime 
:: OTHERWISE t > T[length(T) - \].readJiime 

(4) fill 

The fill function takes as input an incrementaLtrace.tuple_set from the output 
streams of an operator and for each incrementaLtrace-tuple in the set, it creates an empty 
data-tuple for aU other streams in the prototype. 
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APPENDIX B 


EFFECTS OF CONTROL CONSTRAINTS ON 
POSSIBILITY FUNCTIONS 


This appendix defines the effect of each form of constraint contained in the PSDL 
grammar on the possibility function of an operator. The possibility function for an operator 
o is a function of the form, To{Io,rt), where /„ is the input history of the operator o, and rt 
is the last possible time that o could have read its streams for the current firing. The output 
of the possibility function is a set of possible incrementaLtrace_tuples written to the output 
streams of o by the current firing of o. Examples of possibility functions can be found in 
Chapter IV, Section A.3, Examples 5 and 6. 

The main result in this appendix is Lemma l,the Independent Operator Lemma, 
which states that the possibility function of an operator is not dependent on the context in 
which it is placed. 

Lemma 1 Independent Operator Lemma 

Given the same input history and an unlimited number of processors, an operator has 
the same possibility function regardless of whether it is contained in a larger prototype, as 
long as the larger prototype does not introduce input to the operator from a feedback loop. 

Proof: 

This proof is a structural induction over all of the different control constraints in the 
PSDL grammar. First, let us look at the possibility function for an operator o, This 
possibility function produces a set of possible incremental trace tuples for every finite prefix 
of input vectors written to the operator’s input streams. 
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Each of the following sections discusses how each of the control constraints available in 
PSDL affects the possibility function for o. 

1. Triggers Input Guards 

The “Triggered” control constraint defines the conditions which trigger the execution 
of o. The two options, “by all” cind “by some” identify any input streams listed after them 
as data flow streams or sampled streams respectively, and any time a value is written to one 
of those streams, it can only be removed from the stream by a firing of the operator o for 
data flow streams, and a producer operator for sampled streams. Another option which may 
appear in a triggering constraint is an input guard. These appear cis boolean expressions 
that, if satisfied, allow the operator o to fire. 

a. “by all” 

The “by all stream^ef trigger appearing in a control constraint limits the execution 
of the operator o to fire only when there is a new value on each of the streams in streamset. 
The effect of this on is that it limits the read times for which o can produce a set of 
non-empty incrementaLtrace-tuples. Since the output of .Fo is determined only by the input 
history of o, which we have assumed to be the same in any context, this only serves to limit 
the possible output histories. These output histories are the same regardless of whether o is 
contained in a larger prototype or functions independently. 

b. “by some” 

A similar argument can be made for the “by some strearrLjef' trigger. The input 
sequences processed by o are limited to only those sequences of vectors in which at least one 
of the streams listed in stream^set contains a new value. The effect of this limitation is the 
same as in the previous section. 
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c. Input Guards 


Input guards in the triggering condition of an operator, o, define which input values 
can trigger the execution of o. Their effect is to limit the read times at which the operator 
can fire. Since that effect only serves to limit the execution of o, it is the same whether or 
not the operator is contained in a larger prototype or not. 

2. Period 

Operators with a period constraint are declared with a time t. After an initial delay of as 
much as i time, the operator is given a window of i amount of time in which to fire. As long 
as the operator fires early enough to complete its execution before the end of the period, a 
set of possible outputs will be written to its output streams. This set of outputs is produced 
non-deterministically because of the flexibility the operator has in starting its execution. 
This non-deterministic start time will change the time that the operator reads its input 
streams, thereby changing the possible outcome. Since, we are assuming that the number of 
processors is unlimited, we conclude that no matter whether the operator is contained in a 
larger prototype or not, all choices for read times are possible, thus the possibility function 
for the operator will be the same in either case. 

3. Finish Within, Minimum Calling Period & Maximum Response 
Time 

Operators with a finish within, minimum calling period or maximum response time 
constraint are declwed with a time, t. The minimum calling period constraint serves to 
limit the possible read times of the operator, and the finish within and maximum response 
time constraints limit the possible write times of the operator, however these constraints 
are not dependent on the context in which the operator is placed as long as the number of 
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processors is not limited. Therefore, the possibility function for the operator is the same 
whether it is contained in a larger prototype or not. 

4. Constraint Options 

Constraint options include output guards, exceptions and timer operations. Output 
guards can affect the possibility function of an operator, but these are part of the definition 
of the operator. Thus, the effect of these output guards on the possibility function for the 
operator is the same regardless of whether the operator is contained in a larger prototype. 
Exception triggers contained in the implementation of an operator can affect outputs on 
streams of type exception, and their triggering is affected only by the inputs provided to 
the operator, so the exception outputs resulting from possible inputs to the operator would 
be the same regardless of whether the operator is contained in a larger prototype. Timer 
operations affect the outputs on timer dependency edges only. These timer operations affect 
the state of a timer if some predicate evaluated on the inputs to the operator is satisfied. 
Since the inputs to the operator are the same when the operator is contained in a larger 
prototype, the resultant timer state change operations will be the same if the operator is 
contained in a larger prototype. 

Since the control constraints and the output history of an operator can only depend on 
the input received from the data streams and timer dependency edges, and we know these 
to be the same, putting the operator in the context of a larger prototype can not affect its 
possibility function. □ 

It is important to note that Lemma 1 applies equally to operators which are components 
of larger operators, or operators which implement some operation in an abstract data type. 
From our perspective, there is no difference. 
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APPENDIX C 


PROOFS OF THEOREMS 

1. Traces —> FunctionRepresentations IS WELL-DEFINED 
AND A BIJECTION 

THEOREM 2: 

Proof 

1. Show $ is single-valued and a total function. Let r be a trace on a stream, and let 
^'i and ^<2 be two functional representations for r SUCH THAT ^ 

Since ^ ^2, 3 a time t € [0,oo) SUCH THAT ^ 

But, then by the definition of 3n < mm(length($~*(^'i)), length($"*(q'2))) 
SUCH THAT 

$"‘(^'i)[n].va/ue ^ $"*(^'2)[n].wa/ue or 
^"M^i)H-operator $-*(^'2)[n].opera<or or 
$“’(^'i)[n].u)ri<e-<tme ^ ^>~*(^'2)H-w'ri<eJtme or 
^ $~*(^'2)[n].readJime. 

Thus, ^ $“‘(^'2), but we know that = 4>~*(^'2) = r, and 

we have a contradiction. 

Therefore, 4> is well defined. 

2. Show $ is onto. Let 

M= [0,<,) —► [-L,±,0] 

i<i,<2) —► Ia:i,Oi,tri] 

[<n,<n+i) —» [x„,o„,<r„] 

be a mapping in 4'. 
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Then by definition of 


M = ^(([-L, -L, 0,0], [x], Oi, tri, tiDi], • • ■, [x„, On, trn,iw„], ■ ■ •)) 
or tn+i = oo. 

Therefore, $ is onto. 

3. Show r s ==> $(r) 7^ <{>(s) 

Let r and s be two traces on a stream, where r jt s. 

Then 3n < max(length(r), length(s)) SUCH THAT 

r[n].na/ue ^ s[n].i;aiue or r\r^.operator ^ s[n].operator or 
r[n].u;ri<e_ttme ^ s[Ti].torite_<ime or r[n].read-time ^ s[n].readJime. 

If r[Ti].tortte.time ^ s[n].torite_time 

then 3t < min(r[n].ioriteJime, s[n].toriteJime) SUCH THAT 
<I.(r)(t) f $(s)(t). 

If (r[Ti].read-time ^ s[n].read.time or r[n].na/ue ^ s[n].voiue) 
and r[n].toriteJime = s[n].u;rite.time 

then 3t = r[n].u;riteJime = s[n].ioriteJime SUCH THAT 
<I>(r)(t) 7^ 

Therefore, $(r) 7^ <&(s), and $ is one-to-one. 

By 1, 2 fc 3, $ is a Bijection. □ 

2. SLICING THEOREM FOR PSDL PROTOTYPES 

THEOREM 3: Slicing Theorem 

Let Sp(X') be the slice of a prototype P with respect to a set of streams X. Then 

Sp{X) and P have the same prototype behavior on any subset of the streams in Sp(X). 
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Proof 

Let Sp{X) be an arbitrary slice of a prototype P. We show that at any point during 
the execution of Sp{X), both P and Sp(X) have the same truncated prototype behavior 
over the data streams in Sp{X). From this, we conclude that the prototype behavior over 
any subset of the data streams in Sp(X) is the same in both the slice and the prototype. 

Using we view each of the trace tuples in B£;(5p(x)) | ^ as a sequence of vectors, each 
vector containing a data tuple from each data stream in E{Sp{X)) and do an induction over 
the length of the longest sequence. 

Induction Hypothesis : 

If the length of the longest sequence of vectors in 'Be(Sp{X)) is no more than k, then 
B£(5j.(Jf)) is the same in both P and Sp{X). 

Basis : (Sequence of length one) 

The semantics of PSDL determine an initial data tuple for each stream. The read 
time and write time of this initial data tuple are both 0. If the stream is declared as a 
state variable, then the initial data tuple contains a data value specified by the STATE 
declaration, and otherwise it contains the undefined data value J.. The operator field of the 
data tuple contains either the id of the operator containing the state variable declaration 
for the stream, if one is declared, or ±. Since the state variable declarations are the same in 
both P and Sp{X), the B over all of the streams in Sp{X) is the same in both, when the 
length of the longest sequence of vectors is one. 

Induction Step : (Be(s,(x)) is a sequence of length I: + 1) 

Equation 1 shows us that BB(Sp(jr)) 1 (1:+ 1) is completely determined by Be(5^X)) I k. 
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B£:(Sp(X)) I (^ + 1) = 

U \t® U f©f U 

T6B£(s^(x))|* L ser(V(Sp(x))) \oes \p(T.o)<tr \tT<i ///J 

( 1 ) 

Since BE(Sp(;f)) | k is the same in the slice and the entire prototype by the induction 
hypothesis, Be{Sp{X)) 1(^ + 1) must also be the same in the slice and the entire prototype. 

Consider the main subexpression of the right hand side of Equation 1; 

T® U f©f U 

S^V(V(Sp(X))) \oes V(T,o)«r \tr<t ! j j 

This construction defines a set of trace tuples of length A: + 1 in terms of a trace tuple t 
of length k and a set of incremental trace tuples of length one that is derived from T and 
the properties of the slice. This set of trace tuples is a subset of Be(Sp{X)) I (^ + !)• The 
© operation is a function, so, providing the trace tuple, T, and the set of incremental trace 
tuples are the same in both P and Sp(X), the resultant subset of B£;(Sp(x)) | (A: + 1) is the 
same in both P and Sp{X). 

The set of trace tuples, Be{Sf{X)) | ^ is the projected B of P over the streams in Sp{X), so 
any trace tuple, T £ 'Be[Sp[X)) \ k is certainly the same in both P and Sp{X), as Sp{X) is 
a subgraph of P. 

The set of possible incrementad trace tuples, D, used in the above construction is constructed 
using the following equation: 

D= U (©( U (u 

sev{V(Sp{X))) Ves \/.(T,o)<ir \«r<t J / J 

D is constructed by looking at every possible subset of the operators in Sp{X), building the 
set of possible incremental tr2ice tuples for the output streams of that subset and finding the 
union over all subsets. Since the powerset of the the set of operators in Sp{X), P(V’(5p(X))), 
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is the same in both P and Sp{X), then the union over all of the subsets is the same in both 
P and Sp{X) provided that the incremental trace tuples produced for each subset are the 
same in both. 

Pick an arbitrary S' 6 V(V{Sp(X))). We want to construct the set of possible incremental 
trace tuples over the output streams of the operators in S'. To do this, we must look at 
each operator, and construct the set of possible incremental trace tuples over their output 
streams. Then, we take each of those and combine them using the 0 function. Since an 
incremental trace tuple is simply a trace tuple of length one, the function © can be overloaded 
to accomplish this task as well. The operator 0 is a commutative function, so as long as the 
incremental trace tuples produced by each operator are the same in both P and Sp{X), their 
combination using 0 is the same in both P and Sp{X). Accordingly, we pick an arbitrary 
operator, v. Constructing the set of possible incremental trace tuples for o is accomplished 
using the following: 


u 

p{T,o)<ir 

By Lemma 1, we know that the set of incremental trace tuples produced by o is the same in 
both P and Sp{X). Now since we already knew that T is the same in both P eind 5/>(A'), 
and we know that © is a function, we conclude that the resultant set of trace tuples is the 
same in both P and Sp{X), for each T € ^E{Sp(X)) \ k. Further, we conclude that the union 
over all possible trace tuples in B£;(s^(;r)) | k is the same in both P and Sp{X). Therefore, 
Bf;(Sp(x)) I (A: + 1) is the same in both P and Sp{X). 

Since any finite prototype behavior over the set of streams in the slice is the same in both 
P 2ind Sp{X), we conclude that any finite behavior over a subset of the streams in the slice 
is the same in both P and Sp{X). 

Now, we want to show that any coimtably infinite prototype behavior is the same in 
both P and Sp{X). Assume not. If any countably infinite prototype behavior is not 


( A (f,/i/Z (£(/>), :r,(7V(.),tr)))j 
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the same in both, then there must be a finite prefix which is not the same in both P and 
Sp{X). However, according to our induction above, all finite subsequences of B£(5p(x)) are 
the same in both, thus we have a contradiction. Therefore, any countably infinite prototype 
behavior over a subset of the streams in Sp{X) is the same in both P and Sp{X). O 

The construction shown in Equation 1 defines the behavior of a prototype in PSDL. Since 
PSDL is non-deterministic and can be executed in parallel, it is necessary for us to consider 
all possible execution circumstances. What the construction really does is lengthen the 
prototypes behavior one incrementaLtrace_tuple at a time. This incrementaLtrace-tuple 
added to the end of the behavior at some time t is the output of every operator in the 
prototype that is writing to its output streams at precisely time t. This can be every 
operator in the prototype or only one operator in the prototype. 
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APPENDIX D 


PSDL Grammcir 


The following is the grammar listing for the Prototyping System Description Language 
(PSDL) as of 14 November 1991. This version corresponds to the implementation of our 
merging tool. Optional items are enclosed in [ square brackets ]. Items which may appear zero 
or more times appear in { braces }. Terminal symbols appear in BOLDFACE. Groupings 
appear in ( parentheses ). 


psdl 

= {component} 

component 

= data.type 
I operator 

data.type 

= type id typejspec typeJmpl 
type.spec 

= specification [generic typeL-decl] [type.decl] 
{operator id operator.spec} 

[functionality] end 


operator 

= operator id operator.spec operatorJmpl 
operator jpec 

== specification {interface} [function^dity] end 
interface 

= attribute [reqmts.trace] 
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attribute 

= generic type.decl 
I input type.decl 
I output type.decl 

1 states type.decl initially initiaLexpressioii.list 
I exceptions idJist 
I maximum execution time time 

type.decl 

= idJist : typejiame {, idJist ; typejiame} 

typejaame 
= id 

I id [ type.decl ] 


idJist 

= id {, id} 

reqmts.trace 

= required by idJist 

functionality 

= [keywords] [informaLdesc] [formaLdesc] 
keywords 

= keywords idJist 

informaLdesc 

= description { text } 

formaLdesc 

= axioms { text } 

typeJmpl 

= implementation ada id end 

I implementation typejiame {operator id operatorJmpl} end 
operatorjmpl 

= implementation ada id end 
I implementation psdLimpl end 

psdlimpl 

= data.flowjdiagram [streams] [timers] [controLconstraints] [informaLdesc] 

dataJow.diagram 

= graph {vertex} {edge} 
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vertex 


= vertex opJd [: time] 

- time is the maximum execution time 


edge 

= edge id [: time] opJd -+ op_id 
- time is the latency 

opJd 

= id [( [idJist] I [id-list] )] 
streams 

= data stream type.decl 


timers 

= timer idJist 
control-constraints 

= control constraints constraint {constraint} 

constraint 

= operator opJd 

[triggered [trigger] [if expression] [reqmts-trace]] 
[period time [reqmts-trace]] 

[finish within time [reqmts-trace]] 

[minimum calling period time [reqmts-trace]] 
[maximum response time time [reqmts-trace]] 
{ constraint-options } 

constraint-options 

= output idJist if expression [reqmts-trace] 

I exception id [if expression] [reqmtsLtrace] 

I timer-op id [if expression] [reqmts-trace] 


trigger 

= by all idJist 
I by some idJist 


timerjop 

= reset timer 
I start timer 
I stop timer 

initiaLexpression-list 

= initial-expression , initiaLexpression 
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initial-expression 
1 false 

I integerJiteral 
I realJiteral 
I stringJiteral 

I id 

I typejiame . id [( initiaLexpression.list )] 

I ( initiaLexpression ) 

I initiaLexpression binary .op initiaLexpression 
1 unary_op initiaLexpression 

binary .op 

= and 

I or 

I xor 

li 

u 


l/= 

1 + 

I- 

I& 

r 

1 / 

I mod 
I rem 


unary .op 

= not I abs | - | + 


time 

= integerJiter^ll unit 

unit 

= microsec 
I ms 
I sec 
I min 
I hours 
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expressionJist 

= expression {, expression) 

expression 

I false 

I integerJiteral 
I time I realJiteral 

I stringJiteral 

I id 

I type_name . id [( expressionJist )] 

I ( expression ) 

I initial.expression binary.op initiaLexpression 
I unary-op initiaLexpression 

id 

= letter {alphajiumeric} 
reaUiteral 

= integerJiteral . integerJiteral 

integerJiteral 

= digit {digit} 

stringJiteral 

= ” {char} ” 

char 

= any printable character except } 

digit 

= 0 .. 9 

letter 

= a .. z 
I A .. Z 

I- 

alpha_numberic 
= letter 

I digit 

text 

= {char} 
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APPENDIX E 


Ada Implementation Code 


On the following pages are contained the implementation code for the current version 
of the Change-Merge Tool. This tool used the PSDL Abstract Data Type developed n Ada 
by other members of the CAPS Research Team, as well as the PSDL Expander developed 
and implemented by Dr. Berzins. The code for these systems are not included in this 
dissertation. 

The code contained in this appendix is broken up into different files. Each section of 
this appendix will contain a different file. All code Wcis implemented in Ada and compiled 
using the Sim Ada Compiler Version 1.0. 
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1. merge_maiii_pkg 


— COMPONENT NAME 

— USAGE 


— INPUT/OUTPUT 

— AUTHOR 

— DATE OF CREATION 

— LANGUAGE USED 

— COMPILER USED 

— PURPOSE 

— FILES USED 

— NOTES 


PACKAGE MERGE_MAIN_PKG ( merge.main.pkg.s.a ) 

Used to perform all of the housekeeping and interface 
between the CAPS interface and the change-merge system 
developed by Dave Deunpier. 

Jim Brockett 
28 NOVEMBER 1993 
Ada 

Sun Ada 1.0 

Provides three functions used by the Merge Interface; 
merge, find_Base, emd commit_merge. 

This is the module to which the TAE interface code for 
the CAPS merge tool connects. Calls eire made from the 
merge interface to this package. It is TBD whether or 
not the actual merge software is integrated into this 
package or put separately elsewhere. Either way will 
work. The purpose of this packaage is integration 
specification. 


— MODIFICATIONS 


DATE : 19 APRIL 1994 

AUTHOR : Dave Dampier 

PURPOSE : Completed Integration with Change_Merge_Pkg. 

— AFFECTED MODULES ; All 
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with uiiix_prcs; use unix_prcs; 

with unix.dirs; use unix_dirs; 

with text.io; use text.io; 

with a.strings; use a_strings; 

with psdl.program.pkg; use psdl_prograjn_pkg; 

with psdl.io; use psdl.io; 

with expander.pkg: use expander.pkg; 

with chaiige_nierge_pkg; use chaiige_merge_pkg; 

package merge.main is 

procedure merge (BASE.VERSION, 

VERSION.A, 

VERSION.B ; in a.string; 
RESULT : in out a.string; 
CONFLICT : in out booleein); 

procedure find.Base (VERSION.A, 

VERSION.B 
BASE.VERSION 
ERROR 

procedure commit.merge (BASE.VERSION, 

VERSION.A, 

VERSION.B : in a.string; 
RESULT : in out a.string); 


end merge.main; 


in a.string; 
in out a.string; 
in out boolean); 






with Unix; use unix; 
with system; use system; 

package body merge_main is 

prototype_path_error: exception; 

procedure system_call(command : in string) is 
procedure system_C(command :address); 
pragma INTERFACE(C, system.C); 
pragma INTERFACE_NAME(system_C, "_system"); 
temp : constant STRING := commandAASCII.NUL; 
error: integer; 

begin 

system.CCTEMP'ADDRESS) ; 
end system_call; 
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— Local function to extract the name of the prototype from the 

— version string. Raises PROTOTYPE_PATH_ERROR if an a.string without 

— the substring "/.caps/" is received as P. 


function name_of_prototype(P : a_string) return a.string is 

pname : string(l..P.len); — to hold prototype name, 

indeil : integer := P.len; — to iterate through P. 

index2 : integer := 1; 
slash_not_found : boolean := true; 

begin 

for i in 1..P.len loop 
pname(i) := ascii.nul; 
end loop; 

for i in 1..2 loop 

while slash_not_found loop 
indexl indeil - 1; 
if indexl < 1 

then raise prototype_path_error; 
end if; 

if P.s(indexl) = ’/’ 
then 

slash_not.found := false; 
end if; 
end loop; 

slash_not_found := true; 
end loop; 

indexl := indexl + 1; 
while slash.not.found loop 
if P.s(indexl) = ’/’ 
then 

slash.not.found :•= false; 
else 

pname(index2) := P.s(indexl); 
indexl := indeil + 1; 
indez2 := index2 + 1; 
end if; 
end loop; 

return truncate(to.a(pname),index2); 
end name.of.prototype; 
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— Procedure merge reads in three prototypes and cheinge-merges them, 

— returning a file name holding the resultant prototype from the 

— chemge-merge. 


procedure merge (BASE.VERSI ON, 

VERSION.A, 

VERSION.B ; in a.string; 

RESULT ; in out a.string; 
CONFLICT : in out boolean) is 


PROTOTYPE.NAME ; 
FILE.STRING : 

BASEFILE : 

AFILE : 

BFILE : 

MERGEFILE 
BASE : 

OPA 

OPB : 

MERGE : 

TEMP : 


a.string; 

a.string; 

file.type; 

file.type; 

file.type; 

file.type; 

psdl.program; 

psdl.program; 

psdl.program; 

psdl.program; 

status.code; 


— Used to 


hold expzinded file. 


— Used to hold 

— Used to hold 

— Used to hold 

— Used to hold 


base program, 
first modification, 
second modification, 
merged program. 


begin 

— reads in Base prototype 2md puts in ADT. 
put.lineC"change-merging prototypes"); 
put.line("reading base version"); 

PROTOTYPE.NAME :* name.of.prototype(BASE.VERSION); 
system.call("merge.script -p "tBASE.VERSION.si:" "t 

PROTOTYPE.NAME.s&"> "ft"/tmp/temp.base.file.psdl"); 
— builds single file input! 
open(BASEFILE, in.file, "/tmp/temp.base.file.psdl"); 
assign(BASE,empty.psdl.program); 
get(BASEFILE,BASE); 
close(BASEFILE); 

system.call("rm /tmp/temp.base.file.psdl") ; 
expand(BASE); 
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— reads in first modified version of prototype and puts in ADT. 
put_line("reading 1st modified version"); 

system_call("merge.script -p "iVERSIDN.A.s4" "& 

PRGTOTYPE_NAME.sft"> "&"/tmp/temp_a_file.psdl"); 

— builds single file input! 
open(AFILE, in_file, "/tmp/temp_a_file.psdl"); 
assign(OPA,empty_psdl_program); 
getCAFILE.OPA); 

close(AFILE); 

system_call("rm /tmp/temp_a_file.psdl"); 
expand(OPA); 

— reads in second modified version of prototype and puts in ADT. 
put_line("reading 2nd modified version"); 

system_call("merge.script -p "AVERSIDN.B.sA" "t 

PRDTGTYPE_NAME.s&"> "A"/tmp/temp_b_file.psdl"); 

— builds single file input! 
open(BFILE, in.file, "/tmp/temp_b_file.psdl"); 
assign(GPB,empty_psdl_program); 
get(BFILE,OPB); 

close(BFILE); 

system_call("rm /tmp/temp_b_file.psdl"); 
expand(OPB); 

— puts result of performing the merge into the directory result. 
change_merge(BASE. OPA, GPB, MERGE, CONFLICT); 

temp := mkdir(result.s) ; 

split (result ,PRGTGTYPE.NAME,MERGE) ; 

exception 
when use_error •=> 

put_line(standard_error, 

"error: can't create output file, permission denied."); 
when syntax_error «> 

put_line(standard_error, 

" parsing aborted due to syntax error."); 
when semantic_error *> 

put _1ine(St andard.error, 

" semantic error, parsing aborted."); 
when expander_pkg.no_root => 
put _1ine(St andard_error, 

" semantic error - no top level operator, expansion aborted."); 
put_1ine(Standard.error, 

" check for recursive use of the prototype name in an expansion.' 
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when expander_pkg.inultiple_roots => 
put.lineCstandard.error, 

" semantic error - more than one top level operator, 
expansion aborted."); 
put_line(standard_error, 

" check for operators that are not used or"); 
put_line(standard_error, 

" add zm extra top-level operator that decomposes"); 
put_line(standard_error, 

" into the current set of top-level components"); 
put_line(standard_error, 

" if your design has severed top-level components."); 

—when undefined.component => 

put_line(standard_error, 

" semantic error - an operator without a PSDL definition has 

been used."); 

when prototype_path_erTor “> 

put_line("from merge_main_pkg.merge"); 
put_line(standeird_error, 

" path to merge inputs provided by top-level interface was 
incorrect."); 
when constraint_error «> 
put_line(standard_error, 

" constraint.error - merger not working properly."); 
when numeric_error => 

put_line(standard_error, 

" numeric_error - merger not working properly."); 
when program_error •=> 

put_line(st andard_ error, 

" program.error - merger not working properly."); 
when storage_error “> 

put_line(standard_error, 

" storage_error - merger not working properly."); 
when tasking_error => 

put_1ine(Standard_error, 

" tasking_error - merger not working properly."); 
when others *> 

put_line(standard_error, 

" unexpected exception - merger not working properly."); 
end merge; 
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procedure find.Base (VERSION.A, 

VERSION.B : in a_string; 

BASE.VERSION : in out a.string; 
ERROR : in out boolean) is 


begin 

teit.io.put_line("this procedure is not yet implemented"); 
BASE.VERSION := to_a("You must select a base version manually!"); 
ERROR := true; 
end find.Base; 

procedure commit.merge (BASE.VERSION, 

VERSION.A, 

VERSION.B : in a.string; 

RESULT : in out a.string) is 

in.result : a.string :» copy(RESULT); 
temp.string : a.string; 
temp ; status.code; 

function version_num(x : a.string) return a.string is 

vnum : a.string; 
index : integer :« x.len; 

begin 

while x.s(index) /» ’/’ loop 
index := index - 1; 
end loop; 

vnum to.a(x.s(index+l..x.len)) ; 
return vnum; 
end version.num; 

begin 

temp.string (in.result ft to.a("-") ft version.num(VERSION.A) 
ft to.a("_") ft version.num(BASE.VERSION) 
ft to.a("_") ft version.num(VERSION.B)); 
temp :«= mkdir(temp.string.s); 

system.call("mv " ft in.result.s ft "/*.psdl " ft temp.string.s); 
temp rmdir(in.result.E); 

RESULT := copy(temp.string); 
end commit.merge; 
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end merge.i 


2. change_merge_pkg 


— COMPONENT NAME 

— USAGE 

— INPUT/OUTPUT 


— AUTHOR 

— DATE OF CREATION 

— LANGUAGE USED 

— COMPILER USED 

— PURPOSE 

“ FILES USED 


“ NOTES 


PACKAGE CHANGE_MERGE_PKG ( change.merge.pkg.s.a ) 

BASE, A, B: in psdl.program 
MERGE: in out psdl.program 
CONFLICT: out boolean 
Dave Dampier 
19 April 1994 
Ada 

Sun Ada 1.0 

Contains the procedure which performs the change-merge 
operation on PSDL programs. 
psdl_t 3 rpe_s.a, psdl_ct_s.a, psdl_prog_s.a, 
psdl_graph_s.a, prototype_dependoncy_graph_pkg_s.a, 
proto_spec_merge_pkg_s.a, proto_impl_merge_pkg_s.a, 
exp.s.a. 


with a_strings; use a_strings; 

with psdl_component_pkg; use psdl_component_pkg; 
with psdl_concrete_type_pkg; use psdl_concrete_type_pkg; 
with psdl_program_pkg; use psdl_program_pkg: 
with psdl_graph_pkg; use psdl_graph_pkg; 

with prototype_dependency_graph_pkg; use prototype_dopendency_graph_pkg; 

with proto_spec_merge_pkg; use proto_spec_merge_pkg; 

with proto_impl_merge_pkg; use proto_impl_merge_pkg; 

with text_io; use text.io; 

with expression_pkg; use expression.pkg; 

package change_merge_pkg is 
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— This function performs the change_merge operation on PSDL prototypes. 

— Given three prototypes. BASE, A aoid B, the function creates 

— prototype dependency graphs for the three prototypes, and using 

— prototype slicing, it identifies the preserved part of the base 

— in all three versions, and the parts of the changed versions vhich 

— are different from the base. It then combines the three pieces into — 

— a merged graph. If the graph correctly represents the semantic merge — 

— of the three versions, and there are no conflicts, then the merged 

— protot 3 rpe is reconstructed from the merged graph. In the case of a 

— conflict, the exception "merge.conflict" is raised. 


procedure change_merge(BASE, A, B: in psdl_program; 

MERGE: in out psdl.program; 

CONFLICT: out boolean); 

procedure build_prototype(P: in out psdl.component; 

G: in prototype_dependency.graph); 


end change_merge_pkg; 
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package body change_merge_pkg is 


— This function performs the change.merge operation on PSDL prototypes. 

— Given three prototypes, BASE, A and B, the function creates 

— prototype dependency graphs for the three prototypes, and using 

— prototype slicing, it identifies the preserved part of the base 

— in all three versions, and the parts of the changed versions which 
are different from the base. It then combines the three pieces into a 

— merged graph. If the graph correctly represents the semantic merge 

— of the three versions, and there are no conflicts, then the merged 

— prototype is reconstructed from the merged graph. 


procedure change_merge(BASE, A, B: in psdl_program; 

MERGE: in out psdl_program; 

CONFLICT: out boolean) is 

BASEHDLD, AHOLD, BHOLD: psdl_program := empty_psdl_program; 

BASETYPE, ATYPE, BTYPE: psdl.progreun :«= empty_psdl_program; 

ATOMIC.COMP: atomic.operator; 

BASECOMP, ACOMP, BCOMP, MERGECOHP: composite.operator; 

GBASE, GA, GB, GM, PP, APA, APB: prototype.dependency.graph; 
BASESTREAMS, ASTREAMS, BSTREAMS, MERGESTREAMS: type.declaration; 
MERGESTATES: type.declaration; 

MERGEINIT: init.map := empty.init.map; 

MERGEEXCEPTIONS, MERGEKEYWORDS: id.set; 

MERGEMET: millisec := 0; 

MERGE.INF.DESC, MERGE.AX: text; 

BASETRIG, ATRIG, BTRIG, MERGETRIG: trigger.map :« empty.trigger.map; 
BASEEG, AEG, BEG, MERGEEG: exec.guard.map :>= empty.exec.guard.map; 
BASEOG, AOG, BOG, MERGEOG: out.guard.map := empty.out.guard.map; 

BASEET, AET, BET, MERGEET: excep.trigger.map := empty.excep.trigger.map; 
BASETO, ATO, BTO, MERGETO: timer.op.map := empty.timer.op.map; 

BASEPER, APER, BPER, MERGEPER: timing.map := empty.timing.map; 

BASEFW, AFW, BFW, MERGEFW: timing.map :•= empty.timing.map; 
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BASEMCP, AMCP, BMCP, MERGEMCP: timing.map := einpty_timiiig_map; 
BASEHRT, AMRT, BMRT, MERGEMRT: timing.map := empty_timing_map; 
BASEDESC, ADESC, BDESC, MERGEDESC: tejrt; 

MERGEID: psdl.id; 

BASETIMERS, ATIMERS, BTIMERS, MERGETIMERS, V: id.set; 
tempexpression: expression; 
tempoutid: output_id; 
tempexid: excep_id; 

conflict_free_a, conflict_free_b: boolean := true; 
begin 

conflict := false; 


— This section of code is used to extract the psdl components from each 

— of the three programs. It assigns the parent composite operator to its 

— own component variable, and it assigns the atomic operators to holding 

— components, so they can be retrieved later. 


for id:psdl_id,c:psdl_component in psdl_program_map_pkg.scan(BASE) loop 
if component_category(c) = psdl_type 
then 

bind(id,c,BASETYPE); 

else 

if component.granularity(c) « composite 
then 

BASECOMP c; 
else 

bindCid, c, BASEHOLD); 
end if; 
end if; 
end loop; 
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for id:psdl_id,c:psdl_component in psdl.program.map.pkg.scan(A) loop 
if component_category(c) = psdl.type 
then 

bindCid.c.ATYPE); 

else 

if component.granularityCc) = composite 
then 

ACOMP := c; 
else 

bindCid, c. AHOLD); 
end if; 
end if; 
end loop; 


for id:psdl_id,c:psdl_component in psdl_program_map_pkg.scan(B) loop 
if component_category(c) = psdl_type 
then 

bind(id.c.BTYPE); 

else 

if component_granularity(c) = composite 
then 

BCOMP :•= c; 

bind(id. c. BHOLD); 
end if; 
end if; 
end loop; 
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the Merged Specificatic 


— Merge the states 


iiierge_states(MERGESTATES.states(BASECGMP) .states(ACOMP) .states(BCOMP) , 
MERGEINIT. get_init_map(BASECOMP) . get_init_inap(ACDMP) . 
get_init_map(BCOMP)); 


— Merge the Exceptions 


assign(MERGEEXCEPTIONS. merge_id_sets(exceptions(BASECOMP). 

exceptions(ACOMP). exceptions(BCDMP))); 


— Merge the Keywords 


assignCMERGEKEYWORDS. merge.id.sotsCkeywordsCBASECOMP). 

keywords(ACOMP). keywords(BCOMP))); 


— Merge the Informal Description 


MERGE_INF_DESC := merge_text(informal_description(BASECDMP). 

informal_description(ACOMP). 
informal_description(BCOMP)); 


— Merge the Formal Description 


MERGE.AX := merge.text(axioms(BASECOMP) , 
axioms(ACOMP). 
axioms(BCOMP)); 
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— Merge the Maximum Execution Times 


MERGEMET := merge.met(specified_maximum_execution_time(BASECOMP), 
specified_maximum_execution_time(ACOMP), 
specified_maximum_execution_time(BCOMP)); 


— Merge the Implementation 


— Extract the prototype dependency 

— graphs fr&m the psdl components. 


assignCGBASE, build.PDG(BASECOMP)); 
assignCGA, build_PDG(ACOMP)); 
assignCGB, build_PDG(BCOMP)); 


— Create the Preserved Part 


assign(PP, preserved_part(GBASE, GA, GB)); 


— Create the Affected Parts of each 

— modification graph. 


— put_line("Affected Part: A"); 

assign(APA, affocted_part(GA, GBASE)); — First Modification 

— put_line("Affected Part: B"); 

assign(APB, affected_part(GB, GBASE)); — Second Modification 
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— Create the Merged Graph using the 

— Preserved Part of the Base and 

— the Affected Parts of both 

— modifications. 


assign(GM, graph.merge(PP, APA, APB)); 


Merge the streams 


assign(BASESTREAMS, streams(BASECOMP)) ; 
assign(ASTREAMS, streams(ACDMP)); 
assign(BSTREAMS, streams(BCOMP)); 

assignCMERGESTREAMS, merge_streams(BASESTREAMS, ASTREAMS, BSTREAMS)); 


— Merge the timers 


assignCBASETIMERS, timers(BASECOMP)) ; 
as sign(ATIMERS. timers(ACOMP)); 
assignCBTIMERS, timers(BCOMP)); 

assign(MERGETIMERS, merge_timers(BASETIMERS, ATIMERS, BTIMERS)); 


— Merge the triggers 


for id: psdl_id in id_set_pkg.sc2ui(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bind(id, get_trigger(id. BASECOMP), BASETRIG); 
end loop; 

for id: psdl_id in id_set_pkg.scan(vertices(GA)) loop 
if not oq(id, EXT) 

bind(id, get.trigger(id, ACOMP), ATRIG); 
end if; 
end loop; 
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for id: psdl_id in id_set_pkg. scaii(vertices(GB)) loop 
if not eq(id. EXT) 

bindCid, get_trigger(id, BCDMP), BTRIG); 
end loop; 

assign(MERGETRIG, merge_trigger_maps(vertices(GM), 

BASETRIG, ATRIG, BTRIG)) 


— Merge the execution guards 


for id; psdl.id in id_set_pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bind(id, execution_guaLrd(id, BASECOMP) , BASEEG) ; 
end if; 
end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GA)) loop 
if not eq(id, EXT) 
then 

bind(id, execution_guard(id, ACOMP), AEG); 
end if; 
end loop; 

for id: psdl_id in id_set_pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 
then 

bind(id, execution_guard(id, BCOMP), BEG); 
end if; 
end loop; 

assign (MERGEEG, inerge_exec_gU3Lrd_maps (vertices (GM) , 

BASEEG, AEG, BEG)); 
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Merge the output guards 


for e: edge in edge_set_pkg.scan(edges(GBASE)) loop 

assign(tempexpression,output_guard(e.x,e.stream_name,BASECOMP)); 
if not(tempexpression = true_expression) 
then 

tempoutid.op := copy(e.x); 
tempoutid.streaun := copy(e.stream_name) ; 
bind(tempoutid, tempexpression, BASEOG); 
end if; 
end loop; 

for e: edge in edge_set_pkg.scan(edges(GA)) loop 

assign(tempexpression,output_guard(e.x,e.stream_name,ACDMP)); 
if not(tempexpression = true.expression) 
then 

tempoutid.op :«= copy(e.x); 
tempoutid.stream := copy(e.stream_name); 
bind(tempoutid, tempexpression, AOG); 
end if; 
end loop; 

for e: edge in edge_set_pkg.scan(edges(GB)) loop 

assign(tempexpression,output_guard(e.X,e.stream.name,BCOMP)); 
if not(tempexpression * true.expression) 
then 

tempoutid.op := copy(o.x); 
tempoutid.stream :« copy(e.stream_name); 
bind(tempoutid, tempexpression, BOG); 
end if; 
end loop; 

assign(HERGEOG, merge_output_guard_maps(BASEOG,AOG,BDG)); 


— Merge the exception triggers 
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:-Pkg- 


i(GBASE)) loop 


for e: psdl_id in id_set_pkg.scanCexceptionsCBASECDMP)) loop 
assign(tempexpression, exception_trigger(id,e,BASECDMP)); 
if not eqCtempexpression, false.expression) 

tempexid.op := copy(id); 
tempexid.excep := copy(e); 
bindCtempexid, tempexpression, BASEST); 
end if; 
end loop; 

end loop; 

for id: psdl_id in id_set_pkg.scein(vertices(GA)) loop 
if not eq(id, EXT) 
then 

for e: psdl.id in id_set_pkg.scan(exceptions(ACDMP)) loop 
assign(tempexpression, exception.trigger(id,e.ACDMP)); 
if not eq(tempexpression, false_expression) 
then 

tempexid.op := copy(id); 
tempexid.excep ;= copy(e); 
bind(tempexid, tempexpression, AET); 
end if; 
end loop; 
end if; 

end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 
then 

for e: psdl.id in id.8et.pkg.scan(exceptions(BC0MP)) loop 
assign(tempexpreBsion, exception.trigger(id,e,BCOMP)); 
if not eq(tempexpression, false.expression) 
then 

tempexid.op :« copy(id); 
tempexid.excep := copy(e); 
bind(tempexid, tempexpression, BET); 
end if; 
end loop; 

end loop; 

assign(MERGEET,(merge.excep.trigger.maps(BASEET, AET, BET))); 
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— Merge the timer operations 


for id: psdl_id in id_set_pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bindCid, timer_operations(id, BASECOMP), BASETO); 
end if; 
end loop; 

for id: psdl_id in id_Bet_pkg. scan(vertices(GA)) loop 
if not eq(id, EXT) 
then 

bind(id, timer_operations(id, ACOMP), ATO); 
end if; 
end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 
then 

bind(id, timer_operations(id, BCDMP), BTO) ; 
end if; 
end loop; 

assign(MERGETO, merge_timer_op_maps(vertices(GM), BASETO, ATO, BTO)) 


— Merge the periods 


for id: psdl_id in id_set_pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bind(id, period(id, BASECOMP), BASEPER); 
end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GA)) loop 
if not eq(id, EXT) 
then 

bind(id, period(id, ACOMP), APER); 
end if; 
end loop; 
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for id: psdl.id in id_set_plcg. scaii(vertices(GB)) loop 
if not eq(id, EXT) 

bindCid, period(id, BCOMP), BPER); 
end if; 
end loop; 

assign(MERGEPER, merge_period(BASEPER. APER, BPER)); 


— Merge the finish.withins 


for id; psdl.id in id_set_pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bind(id, finish_vithin(id, BASECDMP), BASEFW); 
end if; 
end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GA)) loop 
if not eq(id, EXT) 
then 

bind(id, finish_within(id, ACOMP), AFW); 
end if; 
end loop; 

for id: psdl.id in id.set.pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 

bindCid, finish.within(id, BCOMP), BFW); 
end if; 
end loop; 

assign(MERGEFW, merge.fw.or.nrt(BASEFW. AFW, BFW)); 


— Merge the max response times 


for id: psdl.id in id.set.pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bind(id, maximum.response.time(id, BASECOMP), BASEMRT); 
end if; 
end loop; 


■ 









L(vertices(GA)) loop 


for id: psdl.id in id_set_pkg.scan 
if not eq(id, EXT) 
then 

bindCid, maximmii_response_tiine(id, ACDMP) , AMRT) ; 
end if; 
end loop; 

for id: psdl_id in id_set_pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 
then 

bind(id, inaximum_response_time(id, BCOMP) , BMRT) ; 
end if; 
end loop; 

assign(MERGEMRT, iiierge_fw_or_mrt(BASEMRT, AMRT, BMRT)); 


Merge the minimum calling periods 


for id: psdl_id in id_set_pkg.scan(vertices(GBASE)) loop 
if not eq(id, EXT) 
then 

bindCid, minimum_cadling_period(id, BASECOMP), BASEMCP); 
end if; 
end loop; 

for id: psdl.id in id_set_pkg.scan(vertices(GA)) loop 
if not eq(id, EXT) 
then 

bind(id, minimum_calling_period(id, ACOMP), AMCP); 
end if; 
end loop; 

for id: psdl_id in id_set_pkg.scan(vertices(GB)) loop 
if not eq(id, EXT) 
then 

bind(id, minimum_calling_period(id, BCOMP), BMCP); 
end if; 
end loop; 

assign(MERGEMCP, merge_min_call_per(BASEMCP, AMCP, BMCP)); 
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Merge the implementation descriptions 


BASEDESC := implementation_description(BASECDMP); 

ADESC := implementation_description(ACGMP); 

BDESC := implementation_description(BCOMP); 

MERGEDESC ;= merge_implementation_description(BASEDESC, ADESC, BDESC); 


— Construct the merged program. 


MERGEID := copy(name(BASECOMP)); 

MERGECOMP := make_composite_operator(MERGEID, 

keywords => MERGEKEYWDRDS, 

informal.doscription => HERGE_INF_DESC, 

axioms => MERGE.AX, 

state *> MERGESTATES, 

initialization.map => MERGEINIT, 

exceptions *> MERGEEXCEPTIONS, 

specified.met «> MERGEMET, 

streams => MERGESTREAMS, 

timers => MERGETIMERS, 

trigger «> MERGETRIG, 

exec.guard => MERGEEG, 

out.guard => MERGEOG, 

excep.trigger => MERGEET, 

timer.op •■> MERGETO, 

per »> MERGEPER, 

fw -> MERGEFW, 

mcp ■=> MERGEMCP, 

mrt => MERGEMRT, 

impl.desc «> MERGEDESC); 
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— Compare the the Merged Graph with the Graph of each modification by 

— comparing the slices of each with respect to their affected parts. 

— If the slices are the same, then the merged graph is correct and the 

— program can be rebuilt. Otherwise, there is a conflict that must be 

— resolved. 


build_prototype(MERGECOMP, GM) ; 
conflict_free_a := compare_graphs(GM, GA, APA); 
conflict_free_b := compare_graphs(GM, GB, APB); 
if not conflict_free_a 
then 

put.line("Conflict found in Version.A"); 
conflict := true; 
end if; 

if not conflict_free_b 
then 

put_line("Conflict found in Version_B"); 
conflict := true; 
end if; 


— Return the Merged Program. 


bind(MERGEID,MERGECDMP,MERGE); 
assignCV, vertices(PP)); 

for id: p8dl_id in id_set_pkg.8can(V) loop 
bind(id,f et ch(BASEHOLD,id).MERGE); 
end loop; 

assign(V, vertices(APA)); 

for id: psdl.id in id_set_pkg.scan(V) loop 
if not member(id,MERGE) 
then 

b ind(id,fet ch(AHOLD.id).MERGE); 
end loop; 

assign(V, vertices(APB)); 
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:_pkg.scaii(V) loop 


for id: psdl_id in id_set 
if not memberCid,MERGE) 
then 

bind(id,fetch(BHDLD,id).MERGE); 
end loop; 
end change.merge; 


— This procedure is used to build the merged prototype when the change- 

— merge operation is successful. 


procedure build_prototype(P: in out psdl_component; 

G: in prototype_dependency_graph) is 

A: psdl.graph; 
begin 

assign(A, psdl_graph(G)); 
reinove_vertex(EXT, A) ; 
set_graph(A,P); 
end build_prototype; 

end change_merge_pkg; 








3. proto_spec_merge_pkg 


- COMPONENT NAME ; PACKAGE PROTO_SPEC_MERGE.PKG(proto_spec_)nerge_pkg.s .a) 

- AUTHOR : Dave Dampier 

- DATE OF CREATION: 19 April 1994 


- LANGUAGE USED 

■ COMPILER USED 

- PURPOSE 


— FILES USED 


Ada 

Sun Ada 1.0 

This package provides specifications for the functions 
used to perform change-merges on psdl operator 
specifications. 

psdl_ct_s.a, psdl_ct_b.a, psdl_type_s.a, psdl_type_b.a 
set_s.a, set_b.a, map_s.a, map_b.a, exp_s.a, exp_b.a. 


with system; 
with generic_map_pkg; 
with generic_set_pkg; 
with TEXT.IO; 
with a.strings; 
with psdl_concrete_type_pkg; 
with psdl_component_pkg; 
with expression_pkg; 

package proto_spec_merge_pkg is 


use TEXT.10; 
use a.strings; 
use psdl.concrete.type.pkg; 
use psdl.component.pkg; 
use expression.pkg; 


function MERGE_SEQUENCES(BASE, A, B: type.declaration) 
return type.declaration; 


procedure MERGE.STATES(MERGE: in out type.declaration; 

BASE, A, B: in type.declaration; 
MERGEINIT: in out init.map; 

BASEINIT, AINIT, BINIT: in init.map); 

function MERGE_MET(BASE, A, B: millisec) return millisec; 


ftinction MERGE. ID.SETS (BASE, A, B: id.set) return id.set; 
function MERGE.TEXT(BASE, A, B: text) return text; 
end proto.spec.merge.pkg; 
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package body proto_spec_inerge_pkg 


function merge.sequences(BASE, A, B: type.declaration) 
return type.declaration is 

MERGE : type.declaration; 

TOP : constant psdl.id ;= to.aC'TOP"); 

begin 

assign(MERGE, empty.type.declaration); 
if equal(BASE, A) 
then if equal(BASE, B) 
then assign(MERGE, BASE); 
else assign(MERGE, B); 
end if; 

else if equal(BASE, B) 
then assign(MERGE, A); 
else if equal(A, B) 
then assign(MERGE, A); 
else bind(TOP, null.type, MERGE); 
end if; 
end if; 
end if; 
return MERGE; 
end merge.sequences; 

function merge.t 3 rpes(t_base, t.a, t.b : type.name) return type.name ii 
begin 

if equal(t_base, t.a) 
then 

if equal(t.base, t.b) 
then 

retum(t_base) ; 
else 

return (t.b); 
end if; 
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if equal(t_base, t_b) 
then 

return(t_a); 
else 

if equal(t_a, t_b) 
then 

return(t_a); 
else 

return null_type; 

end if; 

end merge.types; 

procedure merge_states(MERGE: in out type_declaration; 

BASE, A, B: in type.declaration; 

MERGEINIT; in out init.map; 

BASEINIT, AINIT, BINIT: in init.map) is 

init_value : expression; 

base_type, a_type, b_type : type.name; 

begin 

assign(init_value, empty.expression); 
assign(MERGE, empty.type.declaration); 

for id: psdl.id, t: type.name in type_declaration_pkg.scan(BASE) loop 
if memberCid, A) and member(id, B) 
then 

a. type :« type_declaration_pkg.fetch(A,id); 

b. type := type_declaration_pkg.fetch(B,id); 
bind (id, merge_types(t, a.tjrpe, b.type) , MERGE); 
assign(init_value, init_map_pkg.fetch(BASEINIT,id)); 
if eq(init.value,init.map.pkg.fetch(AINIT,id)) 

then 

if eq(init.value,init.map.pkg.fetch(BINIT,id)) 
then 

bind(id,init_value,MERGEINIT); 

bind(id,init.map.pkg.fetch(BINIT,id),MERGEINIT); 
end if; 
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iit_map_pkg .fetch (BINIT, id) ) 


then 

bind(id,init_map_pkg.fetch(AINIT,id).MERGEINIT); 
else 

if eq(iiiit_map_pkg.fetch(AINIT,id) , 

init_iiiap_pkg. fetch (BINIT, id) ) 

then 

bind(id,init_map_pkg.fetch(AINIT,id).MERGEINIT); 
else 

bind(id,conflict.expression,MERGEINIT); 
end if; 

end loop; 

for id: psdl_id, t: type.name in type_declaration_pkg.scan(A) loop 
if not meinber(id, BASE) and niember(id, B) 
then 

base.type := null.type; 

b_type := type_declaration_pkg.fetch(B,id); 
bind(id, merge_types(base_typ6, t, b_type), MERGE); 
assign(init_value, init_inap_pkg.fetch(AINIT,id)) ; 
if eq(init_value,init_map_pkg.fetch(BINIT,id)) 
then 

bind(id,init_value,MERGEINIT); 
else 

bind(id,conf1ict.expression,MERGEINIT); 
end if; 
end if; 
end loop; 
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for id: psdl_id, t: type_name in type_declaration_pkg.scan(B) loop 
if not member(id, BASE) and memberCid, A) 

base.type := null.type; 

a_type := type_declaration_pkg.fGtch(A,id); 
bindCid, inerge_types (base_type, a.type, t) , MERGE); 
assignCinit.value, init_map_pkg.fetch(BINIT,id)); 
if eq(init_value,init_map_pkg.fetch(AINIT,id)) 

bind(id,init_value,MERGEINIT); 
else 

bind(id,conflict.expression,MERGEINIT); 
end if; 
end if; 
end loop; 
end merge.states; 


function merge.met(BASE, A, B: millisec) return millisec is 
A.DIFF.BASE, B.DIFF.BASE, A_INT_B: millisec; 
begin 

if A <= B 

then A.INT.B B; 

else A.INT.B A; 

end if; 
if BASE <- A 

then A.DIFF.BASE := system.max.int; 
else A.DIFF.BASE ;«= A; 
end if; 


if BASE <*= B 

then B_DIFF_BASE := system.max.int; 
else B.DIFF.BASE := B; 
end if; 

if A.DIFF.BASE <= A.INT.B 
then if A.DIFF.BASE <- B.DIFF.BASE 
then return A.DIFF.BASE; 
else return B.DIFF.BASE; 
end if; 

else if A.INT.B <•= B.DIFF.BASE 
then return A.INT.B; 
else return B.DIFF.BASE; 
end if; 
end if; 

end merge.met; 
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(BASE, A, B: id.! 


function merge_id_sets(BASE. A, B: id.set) return id_s( 
A.DIFF.BASE, B.DIFF.BASE, MERGE: id.set; 


begin 

assign(A_DIFF.BASE, empty.id.set); 
assign(B.DIFF.BASE, empty.id.set); 
assignCHERGE, empty.id.set); 
difference(A, BASE. A.DIFF.BASE); 
difference(B, BASE, B.DIFF.BASE); 
for id: psdl.id in id.set.pkg.scan(A) loop 
if memberCid, B) 

add(id, MERGE); 
end if; 
end loop; 

for id: psdl.id in id.set_pkg.scan(A.DIFF.BASE) loop 
if not memberCid, MERGE) 
then 

add(id, MERGE); 
end loop; 

for id: psdl.id in id.set.pkg.scan(B.DIFF_BASE) loop 
if not memberCid, MERGE) 
then 

add(id, MERGE); 
end if; 
end loop; 
return MERGE; 
end merge.id.sets; 
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function merge.teit(BASE, A, B: text) return text is 
begin 

if eq(BASE, empty.text) and eq(A, empty.text) and eq(B, empty.text) 
then return empty_text; 
else if eqCBASE, A) 
then if not eq(BASE, B) 
then return B; 
else return BASE; 
end if; 

else if eqCBASE, B) 
then return A; 
else if eq(A, B) 
then return A; 

else return to_a("**Text Conflict**"); 
end if; 
end if; 
end if; 
end if; 

end merge_text; 
end proto.spec_merge_pkg; 
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4. proto_impLmerge_pkg 


— COMPONENT NAME 

— USAGE 

— AUTHOR 

— DATE OF CREATION 

— LANGUAGE USED 

— COMPILER USED 

— PURPOSE 


: PACKAGE PROTO.IMPL.MERGE.PKG(proto_impl_merge_pkg_s.a) 
; Used to perform charge-merging on PSDL program 
implementations. 

; David A. Dampier 
: 19 April 1994 
: Ada 

: Sun Ada 1.0 

: Provides specifications for the functions necessary 
to merge PSDL Implementations. 


with system; 

with TEXT.IO; use TEXT.IO; 
with a_strings; use a.strings; 
with generic_map_pkg; 
with generic_set_pkg; 

with psdl_concrete_type_pkg; use psdl_concrete_type_pkg; 
with psdl_component_pkg; use psdl_component_pkg; 
with proto.spec_merge_pkg; use proto.spec.merge.pkg; 
with eipression.pkg; use expression.pkg; 

package proto.impl.merge.pkg is 

function merge_streams(BASE, A, B: type.declaration) 

return type.declaration; 

function merge_timers(BASE, A, B: id.set) return id.set 
renames proto.spec_merge.pkg.merge_id.sets; 

function merge.trigger.maps(VERTS: id.set; BASE, A, B: trigger.map) 

return trigger.map; 

function merge.exec.guard.maps(VERTS: id.set; BASE, A, B: exec.guard.map) 

return exec.guard.map; 
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function merge.output_guard_inaps(BASE, A, B: out.guard.map) 

return out.guard.mapr 

function merge_excep_trigger_maps(BASE, A, B: excep.trigger.map) 

return excep.trigger.map; 

function merge.timer.op.maps(VERTS: id.set; BASE, A, B: timer.op.map) 

return timer.op.map; 

function merge.period(BASE, A, B: timing.map) return timing.map; 

function merge_fw.or.mrt(BASE, A, B: timing.map) return timing.map; 

function merge.min_call_per(BASE, A, B: timing.map) return timing.map; 

function merge.implementation.description(BASE, A, B: text) return text 
renames proto.spec.merge.pkg.merge.text; 

end proto.impl.merge.pkg; 
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package body proto_inipl_merge_pkg is 

function merge_types(t_base, t_a, t_b : type_name) return type_name is 
begin 

if equal(t.base, t_a) 
then 

if equal(t_base, t_b) 
then 

retum(t_base) ; 
else 

return(t_b); 
end if; 
else 

if equal(t_base, t_b) 
then 

return(t_a); 
else 

if equal(t_a, t_b) 
then 

return (t_a) ; 
else 

return null_type; 
end if; 

end merge.types; 

function iBerge_8treains(BASE, A, B: type.declaration) 
return type.declaration is 
MERGE: type.declaration; 
base_type, a_type, b_type : type.neune; 

begin 

assign(MERGE, empty_t 3 rpe_declaration) ; 

for id: psdl.id, t: type.name in type_declaration_pkg.scan(BASE) loop 
if member(id. A) and memberCid, B) 
then 

a_type type_declaration_pkg.fetch(A,id); 

b_type type_declaration_pkg.fetch(B,id) ; 

bind(id, merge.types(t, a.type, b_type), MERGE); 
end if; 
end loop; 


179 





for id: psdl.id, t: type.name in type_declaration_pkg.scaii(A) loop 
if not member(id, BASE) and memberCid, B) 
then 

base_type := null_type; 

b_type := type_declaration_pkg.fetch(B,id); 
bind(id,merge_types(base_type. t, b_type), MERGE); 
end if; 
end loop; 

for id: psdl_id, t: type.name in type_declaration_pkg.scan(B) loop 
if not memberCid, BASE) and memberCid, A) 
then 

base_type := null.type; 

a_type := type_declaration_pkg.fetchCA,id); 
bindCid,merge_typesCbase_type,a_type, t), MERGE); 
end if; 
end loop; 
return MERGE; 
end merge_streams; 

function merge.triggersCBASE, A, B: trigger) return trigger is 
MERGE: trigger; 

conflict_trigger : trigger :* Ctt => by.all, 

streams *> id_set_pkg.addCto_aC"TDP"), 

id_set_pkg.empty)); 

begin 

if eqCBASE, A) 
then 

if eqCBASE, B) 
then 

MERGE.tt BASE.tt; 
assignCMERGE.streams, 

merge_id_setsCBASE.streams, A.streams, B.streams)); 
return MERGE; 
else 

return B; 
end if; 
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if eqCBASE, B) 
then 

return A; 

if eqCBASE, B) 
then 

return A; 
else 

return conflict_trigger; 
end if; 
end if; 
end if; 

end merge.triggers; 

function merge_trigger_maps(VERTS: id.set; BASE, A, B: trigger_inap) 

return trigger.map is 


MERGE: trigger.map; 

base_trig, a_trig, b.trig, merge.trig : trigger; 
begin 

assignCMERGE, einpty_trigger_map) ; 
for id : psdl.id in id_set_pkg.scan(VERTS) loop 
base.trig :« fetch(BASE,id); 

a. trig :* fetch(A,id); 

b. trig := fetch(B,id); 

merge.trig :<= merge_triggers(base_trig, a.trig, b.trig); 
bind(id, merge.trig, MERGE); 
end loop; 
return MERGE; 
end merge.trigger.maps; 

function merge_expressions(BASE, A, B :expression) return expression is 

local.base : expression; 
local.a : expression; 
loc 2 J..b : expression; 

conflict.expression : constant expression := 

create.identifier(to.a("**CDNFLICT‘i‘*")) ; 
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begin 

assign(local_base, BASE); 
assign(local_a, A); 
assign(local_b, B); 
if eq(local_BASE, local.a) 
then 

if eqClocal.BASE, local.B) 
then 

return(local.BASE); 
else 

retum(local_B); 
end if; 
else 

if eq(local_BASE, local_B) 
then 

retum(local_A); 

if eq(local_A, local_B) 
then 

return(local.A); 
else 

return conflict.expression; 
end if; 
end if; 
end if; 

end merge.expressions; 

function merge_exec_guard_inaps(VERTS: id.set; BASE, A, B: exec.guard.jnap) 

return exec.guard.map is 

MERGE: exec_guard_nap; 

base.eg, a_eg, b_eg, merge.eg : expression; 
begin 

assign(MERGE, empty_exec_guard_map); 
for id ; psdl.id in id_set_pkg.scan(VERTS) loop 
assign(base.eg, fetch(BASE,id)); 
assign(a_eg, fetch(A,id)); 
assign(b_og, fetch(B,id)); 

assign(Derge_eg, iiierge_expressions(base_eg, a_eg, b_eg)); 
bind(id, merge.eg, MERGE); 
end loop; 
return MERGE; 

end merge.exec.guaxd.maps; 
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function merge_output_guard_maps(BASE, A, B: out_guard_map) 

return out_guard_map 


MERGE: out_guard_map empty_out_guard_map; 
base.og, a_og, b_og, merge.og : expression; 

for id : output_id, e: expression in out_guard_inap_pkg. scan(BASE) lo 
if member(id.A) and member(id,B) 
then 

assign(a_og, fetch(A,id)); 
assign(b_og, fetch(B,id)); 

assign(merge.og, merge_expressions(e, a_og, b_og)); 
bind(id, merge_og, MERGE); 
end if; 
end loop; 

for id : output_id, e : expression in out_guard_map_pkg.scan(A) loop 
if not member(id, MERGE) 
then 

if member(id, B) 
then 

assign(base.og, empty.expression); 
aBsign(b_og, fetch(B,id)); 

assign(merge_og, merge_expressions(base_og, e, b_og)); 
bind(id, merge.og, MERGE); 
else 

if not member(id, BASE) 
then 

bind(id. e, MERGE); 
end if; 
end if; 
end if; 
end loop; 

for id : output.id, e : expression in out_guard_map_pkg.scan(B) loop 
if not member(id, MERGE) and not member(id, BASE) 
then 

bind(id, e, MERGE); 
end if; 
end loop; 
return MERGE; 

end merge_output_guard_maps; 


183 








3p_trigger.maps(BASE, A, B: 


eicep.trigger.map) 
return excep.trigger.map : 


MERGE: excep.trigger.map; 

base.et, a.et, b.et, merge.et : expressic 


assignCMERGE, empty.eicep.trigger.map); 

for id:eicep.id,e:expression in excep.trigger.map.pkg.scan(BASE) loop 
if member(id,A) and member(id,B) 
then 

assign(a_et, fetch(A,id)); 
assign(b_et, fetch(B,id)); 

assign(merge.et, merge_expressions(e, a.et, b.et)); 
bind(id, merge.et, MERGE); 
end if; 
end loop; 

for id:excep_id,e:expression in excep.trigger.map.pkg.scan(A) loop 
if not member(id, MERGE) 
then 

if member(id, B) 
then 

assign(base.et, empty.expression); 
assign(b.et, fetch(B,id)); 

assign(merge_et, merge.expressions(base.et, e, b.et)); 
bind(id, merge.et, MERGE); 
else 

if not member(id, BASE) 
then 

bind(id, e, MERGE); 
end if; 
end if; 
end if; 
end loop; 

for id:excep_id,e:expression in excep.trigger.map_pkg.scan(B) loop 
if not member(id, MERGE) and not member(id, BASE) 
then 

bind(id, e, MERGE); 

end loop; 
return MERGE; 

end merge_excep.trigger.maps; 
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function merge_timer_op_sets(BASE,A,B;timer.op_set) return timer.op.set is 
MERGE : timer_op_set; 
begin 

for t_op : timer.op in timer.op_set_pkg.scan(BASE) loop 
if member(t_op,A) 
then 

if member(t_op,B) 

add(t.op,MERGE); 
end if; 
end if; 
end loop; 

for t.op : timer.op in timer.op.set.pkg.scan(A) loop 
if not memberCt.op,MERGE) 
then 

if member(t.op,B) 
then 

add(t.op,MERGE); 
end if; 
end if; 
end loop; 

for t.op : timer.op in timer.op.set_pkg.scan(B) loop 
if not member(t.op,MERGE) 
then 

if member(t.op,A) 
then 

add(t.op,MERGE); 
end if; 
end if; 
end loop; 
return MERGE; 
end merge.timer.op.sets; 
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function merge_timer_op_maps(VERTS: id_set; BASE, A, B: timer_op_map) 

return timer_op_map 


MERGE: timer_op_map; 

base_set, a_set, b_set, merge.set : timer_op_set; 
begin 

assign (MERGE, empty_tiiner_op_map) ; 
for id : psdl.id in id_set_pkg.scan(VERTS) loop 
assign(base_set, fetch(BASE,id)); 
assign(a_set, fetch(A,id)); 
assign(b_set, fetch(B,id)); 

assign(merge_set, merge_timer_op_sets(base_set, a_set, b_set)); 
bind(id, merge_set, MERGE); 
end loop; 
return MERGE; 
end merge_timer_op_maps; 

function merge_tiniing_data(BASE, A, B: millisec) return millisec is 

if BASE = A 
then if BASE * B 
then return BASE; 
else return B; 
end if; 

else if BASE B 
then return A; 
else if A = B 
then return A; 
else return system.mai.int; 
end if; 
end if; 
end if; 

end merge_timing_data; 
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function merge_period(BASE, A, B: timing.map) return timing.map is 

MERGE: timing.map; 

BASEVAL, AVAL, BVAL: millisec := 0; 

begin 

assign (MERGE, eiiipty_tiiiiing_iiiap) ; 

for id: psdl_id, m: nillisec in tiining_inap_pkg. scan (BASE) loop 
if member(id. A) and meiiiber(id,B) 

AVAL := fetch(A, id); 

BVAL := fetch(B, id); 

bind(id, merge_timing_data(m,AVAL,BVAL), MERGE); 
end if; 
end loop; 

for id: psdl_id, m: millisec in timing_map_pkg.scan(A) loop 
if not member(id, MERGE) and not member(id,BASE) 
then 

if member(id, B) 
then 

BVAL :« fetch(B, id); 
if m /“ BVAL then 
bind(id, system.max.int, MERGE); 
end if; 
else 

bind(id, m, MERGE); 
end if; 
end if; 
end loop; 

for id: psdl_id, m: millisec in timing_map_pkg.scan(A) loop 
if not member(id. A) and not member(id,BASE) 
then 

bind(id, m, MERGE); 
end if; 
end loop; 
return MERGE; 
end merge_period; 
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function merge_fw_or_inrt(BASE, A, B: timing.map) return timing.map 

MERGE: timing.map; 

BASEVAL, AVAL, BVAL: millisec := 0; 

begin 

assign(MERGE, empty_timing_map); 

for id: psdl.id, m: millisec in timing.map.pkg.scan(BASE) loop 
if member(id. A) and member(id,B) 
then 

AVAL := fetch(A, id); 

BVAL := fetch(B, id); 

bind(id, merge_met(m,AVAL,BVAL), MERGE); 
end if; 
end loop; 

for id: psdl_id, m: millisec in timing_map_pkg.scan(A) loop 
if not member(id, MERGE) and not member(id,BASE) 
then 

if member(id, B) 
then 

BVAL fetch(B, id); 
if m /» BVAL then 

bind(id, system.max_int, MERGE); 
end if; 
else 

bind(id, m, MERGE); 
end if; 
end if; 
end loop; 

for id: psdl.id, m: millisec in timing_map_pkg.scan(A) loop 
if not member(id. A) and not member(id,BASE) 
then 

bind(id, m, MERGE); 
end if; 
end loop; 
return MERGE; 
end merge_fw_or_mrt; 




function inerge_i!icp(BASE, A, B: millisec) return millisec is 

A.DIFF.BASE, B_DIFF_BASE, A.INT.B: millisec; 

begin 

if A >= B 

then A.INT.B := B; 
else A.INT.B := A; 
end if; 
if BASE <* A 
then A.DIFF.BASE := A; 
else A.DIFF.BASE system.meuc.int; 
end if; 
if BASE <«= B 
then B.DIFF.BASE := B; 
else B.DIFF.BASE := system.max.int; 
end if; 

if A.DIFF.BASE >= A.INT.B 
then if A.DIFF.BASE >= B.DIFF.BASE 
then return A.DIFF.BASE; 
else return B.DIFF.BASE; 
end if; 

else if A.INT.B >= B.DIFF.BASE 
then return A.INT.B; 
else return B.DIFF.BASE; 
end if; 
end if; 

end merge.mcp; 





function merge_inin_call_per(BASE, A, B: timing.map) return timing.map 


MERGE: timing.iiiap; 

BASEVAL, AVAL, BVAL: millisec := 0; 

begin 

assignCMERGE, empty_timing_map); 

for id: psdl_id, m: millisec in timing_map_pkg.sccin(BASE) loop 
if memberCid, A) and member(id,B) 
then 

AVAL := fetch(A. id); 

BVAL := fetchCB, id); 

bindCid, merge.mcp(m.AVAL.BVAL), MERGE); 
end loop; 

for id: psdl_id, m: millisec in timing_map_pkg.scan(A) loop 
if not memberCid, MERGE) and not memberCid,BASE) 
then 

if memberCid, B) 
then 

BVAL :» fetchCB. id); 
if m /« BVAL then 

bindCid, system.max.int, MERGE); 
end if; 
else 

bindCid, m, MERGE); 
end if; 
end if; 
end loop; 

for id: psdl_id, m: millisec in timing_map_pkg.scanCA) loop 
if not memberCid, A) and not memberCid,BASE) 
then 

bindCid, m, MERGE); 
end if; 
end loop; 
return MERGE; 
end merge_min_call_per; 

end proto_impl_merge_pkg; 
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i. prototype_dependency_graph_pkg 


— COMPONENT NAME : PACKAGE PROTOTYPE.DEPENDENCY.GRAPH.PKG 


( prototype_dependeiicy_graph_pkg_s . a ) 

— USAGE : Used to perform change-merging on prototype 

dependency graphs. 

— AUTHOR : David A. Dampier 

— DATE OF CREATION : 19 April 1994 

— LANGUAGE USED : Ada 

— COMPILER USED : Sun Ada 1.0 

— PURPOSE : Provides specifications for the functions necessary 

to merge PSDL prototype dependency graphs. 


with TEXT.IO; use TEXT.IO; 
with a_strings; use a.strings; 
with generic_map_pkg; 
with generic_set_pkg; 

with psdl_concreto_type_pkg; use psdl_concrete_type_pkg; 

with psdl_graph_pkg; use psdl_graph_pkg; 

with psdl_component_pkg; use psdl_component_pkg; 

package prototype_dependency_graph_pkg is 

procedure assign(z: in out edge.set; y: in edge.set) renames 
edge.s et _pkg.assign; 

type prototype.dependency.graph is new psdl.graph; 

function empty.PDG return prototype.dependency.graph; 

function build_PDG(P: in psdl.component) 

return prototype.dependency.graph; 

function preserved.part(Base,A,B: in prototype.dependency.graph) 
return prototype.dependency.graph; 

function create.slice(G: in prototype.dependency_graph;E: in edge) 
return prototype.dependency.graph; 

function create.slice(G: in prototype.dependency.graph;E: in edge.set) 
return prototype.dependency.graph; 
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function conipecre_slices(Sl,S2: in prototjrpe.dependency.graph) 

return boolean; 

function grapli_union(Gl,G2; in prototype_dependency_graph) 

return prototype_dependency_graph; 

fimction graph_inerge(Gl,G2,G3: in prototype_dependency_graph) 
return prototype_dependency_graph; 

function affected.part(G,B: in prototjrpe.dependency.graph) 

return prototype.dependency.graph; 

function compare.graphsCGl,G2,S: in prototype.dependency.graph) 

return boolean; 

end prototype.dependency.graph.pkg; 
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package body prototype_dependency_graph_pkg is 


fimction eiiipty_PDG return prototype_dependency_graph is 
begin 

return empty_psdl_graph; 
end; 


— This function takes a PSDL component and creates from the 

— implementation graph, a prototype dependency graph. 


function build_PDG(P; in psdl_component) 

return prototype_dependency.graph is 


G; prototype.dependency.graph; 

0: psdl.id; 

VERTS: id.set; 

OUTEDGE: a.string; 

begin 

assignee, empty.PDG); 

assignee, prototype.dependency.graphegrapheP))): 
assigneVERTS, vorticesee)); 

for id: psdl.id in id.set.pkg.scaneVERTS) loop 
if equalesuccessorseid, e), empty.id.set) 
then 

OUTEDeE := copyeid&EXT); 
assignee, add.edgeeid, EXT, OUTEDeE, e, 0)); 
if not has.vertexeEXT, e) 
then 

assigneo, add.vertexeEXT, e)); 
end if; 
end if; 
end loop; 
return e; 
end build.PDe; 
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This function calculates the part of Base,A,and B which 


identical 


function preserved_part(Base,A,B: in prototype_dependency_graph) 
return prototype_dependency_graph is 

PP, SI, S2, S3: prototype.dependency.graph; 

E; edge; 

D: edge.set; 

begin 

assign(PP, empty.PDG); 
assign(Sl, empty.PDG); 
assign(S2, empty.PDG); 
assign(S3, empty.PDG); 
assign(D, edges(Base)); 
for E;edge in edge.set.pkg.scan(D) loop 
assign(Sl, create.sliceCBase, E)); 
assign(S2, create.slice(A, E)); 
assign(S3, create.slice(B, E)); 

if compare.slices(SI, S2) and then compare.slices(Sl, S3) 
then 

assign(PP, graph.union(Sl, PP)); 
end if; 
recycle(Sl); 
recycle(S2); 
recycle(S3); 
end loop; 
return PP; 
end preserved.part; 
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This function creates a graph which contains only the part of G which- 
affects the output values written to the edge E. 


function create_slice(G: in prototype_dependency_graph;E: in edge) 
return prototype_dependency_graph is 

SI, S2: prototype_dependency_graph; 

D; edge; 

C: edge_set; 

begin 

assign(Sl, empty.PDG); 
assign(S2, empty_PDG); 
if has_edge(E.x, E.y, G) then 

as sign(S1, add.edge(E.x,E.y,E.stream.name, 

SI, latency(E.x,E.y,E.streain_naine,G))) ; 
assign(Sl, add_vertex(E.x, SI, maLxiinuiii_execution_time(E.x,G))); 
if eq(E.y, EXT) 
then 

assign(Sl, add.vertex(E.y, SI)); 
end if; 

assignee, edges(G)); 
while not compare.slicesCSl, S2) loop 
assign(S2, SI); 

for D:edge in edge.sot.pkg.scan(C) loop 

if (has.vertex(D.y, SI) and not eq(D.y, EXT)) 
then 

assign(Sl, add.edge(D.x,D.y, 

D.Stream.name,S1, latency(D.x,D.y,D.stream.name,G))); 
assignCSl, add.vertex(0.x, SI, 

iiiaximuin.execution.time(D.x,G))) ; 

end if; 
end loop; 
end loop; 
end if; 
return SI; 
end create.slice; 
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— This function calculates the union of the graphs G1 and G2. 


function graph_union(Gl,G2; in prototype_dependency_graph) 

return prototype_dependency_graph is 

G: prototype_dependency_graph; 

V: psdl.id; 

W: id_set; 

E: edge; 

D: edge_set; 

begin 

assign(G, empty.PDG); 
assign(G.Gl): 
assign(W, vertices(G2)); 
assign(D, edges(G2)); 

for V;psdl_id in id_set_pkg.scan(W) loop 
if not(has.vertex(V, G)) 
then 

assign(G, add_vertex(V, G,inaxiinuiii_execution_time(V,G2))) ; 
end if; 
end loop; 

for E:edge in edge.set.pkg.scan(D) loop 
if not (edge.set.pkg.member(E,edges(G))) 
then 

assign(G, add.edge(E.x,E.y, 

E.stream.name, G,latency(E.x,E.y,E.stream.name,G2))); 

end if; 
end loop; 
return G; 
end graph.union; 
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This fiinctic 


lerges three graphs using the function graph_uni( 


function graph_merge(Gl,G2,G3: in prototype_dependency_graph) 

return prototype_dependency_graph is 

G: prototype_dependency_graph; 

begin 

assignee, empty_PDG); 
assignee, graph_unioneGl, G2)); 
assignee, graph.unionec, G3)); 
return G; 
end graph_merge; 


— This fTinction calculates the part of G which is not contained in P. 


function affected_parteG,B: in prototype_dependency_graph) 

return prototype_dependency_graph is 

A, SG, SB: prototype_dependency.graph; 

E: edge; 

D; edge.set; 

begin 

assigneA, empty.PDG); 
assigneSG, empty.PDG); 
assigneSB, empty.PDG); 
assignee, edgesec)); 

for E:odge in edge_set_pkg.scaneD) loop 
assigneSG, create.sliceeG, E)); 
assigneSB, create.sliceeB, E)); 
if not compare.sliceseSG, SB) 
then 

assigneA, add_edgeeE.x,E.y, 

E.stream.name, A, latencyeE.x,E.y,E.stream_naine,G))) ; 
assigneA, add.vertexeE.x, A, maximum.execution.timeeE.x, G))); 
assigneA, add.vertexeE.y, A, maiimum.execution.timeeE.y, G))); 
end if; 
end loop; 
return A; 

end affected.part; 
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— This function compares the graphs G1 and G2 with respect to the 

— slice S. If each of G1 and G2 are the same with respect to S, then 
it returns TRUE. 


function compare_graphs(Gl,G2,S: in prototype_dependency_graph) 
return boolean is 


E: edge_set; 

T, V: prototype_dependency_graph; 
begin 

assignCT, empty_PDG); 
assign(V, empty_PDG); 
assign(E, edges(psdl_graph(S))): 
assign(T, create_slice(Gl, E)); 
assignCV, create_slice(G2, E)); 
retum(compare_slices(T, V)); 
end compaje_graphs; 

end prototype_dependency_graph_pkg; 
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